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Chapter  1 

Introduction 


Object-oriented  programming  languages,  such  <is  Smalltalk-80  [GR83],  provide  program¬ 
mers  with  powerful  tools.  One  of  these  tools  is  a  generic  invocation  (or  message  passing) 
mechanism,  which  allows  code  to  manipulate  instances  of  different  types.  To  reason 
about  programs  that  use  generic  invocation,  programmers  often  classify  types  by  how 
instances  of  that  type  behave.  If  each  instance  of  type  S  behaves  like  an  instance  of  type 
T,  then  S  is  called  a  subtype  of  T.  Progranuners  hope  that  if  their  code  works  correctly 
when  it  operates  on  instances  of  some  type  T,  then  their  code  will  also  work  correctly 
on  instances  of  subtypes  of  T.  However,  since  they  lack  the  formal  tools  to  guide  their 
classiftcation  of  types  and  their  reasoning,  their  reasoning  lacks  certainty. 

In  this  dissertation,  we  take  the  following  steps  towards  a  foundation  for  reeisoning 
about  programs  that  use  generic  invocation. 

•  We  present  a  formal  definition  of  subtyping  among  abstract  types. 

•  We  present  formal  techniques  for  specifying  and  verifying  programs  that  use  generic 
invocation. 

1.1  Generic  Invocation 

To  explain  generic  invocation,  we  must  first  define  a  few  terms.  An  abstract  data  type 
is  a  description  of  a  set  of  instances  (or  objects)  and  a  set  of  operations  that  create  and 
manipulate  them  [LG86].  A  class  is  a  program  module  that  implements  an  abstract 
da^o.  type.  A  class  defines  a  representation  for  instances  and  implements  the  various 
operations  of  the  abstract  type  with  procedures.  Each  abstract  data  type  has  a  name, 
and  we  give  a  class  the  same  name  as  the  abstract  type  it  implements.  The  names  of 
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abstract  types  are  the  types  used  in  type  checking.  Each  object  is  an  instance  of  the 
class  that  created  it,  and  thus  an  instance  of  the  abstract  type  that  the  class  implements. 
Therefore  each  instance  has  one  and  only  one  class  and  type,  and  its  class  and  type  have 
the  same  name.  For  example,  an  instance  of  type  Text-Window  would  also  be  an  instance 
of  the  class  named  Text -Window. 

The  invocations  of  read-line(io)  in  the  second  and  last  lines  of  the  Trellis/Owl 
[SCB*S6]  [0BrS5]  [SCVV85]  program  of  Figure  1.1  are  generic  invocations,  because  they 
are  syntactically  identical  and  yet  may  result  in  the  running  of  different  procedures.  In 
the  second  line  of  the  program,  io  denotes  an  instance  of  Text-Window,  so  the  generic 
invocation  mechanism  runs  code  that  is  part  of  the  class  Text-Window.  In  the  last  line 
of  the  program,  code  from  the  class  lO-Strezim  will  be  run  if  io  denotes  an  instance  of 
lO-Stream,  and  otherwise  the  code  from  the  cl2iss  Text-Window  will  be  run.  Notice  that 
in  the  last  line,  the  choice  of  what  code  to  invoke  cannot  be  made  before  the  result  of 
the  if  expression  is  known. 

Generic  invocation  is  sometimes  called  message  passing  because  one  can  think  of 
read-line  (io)  as  sending  the  message  “read-line”  to  the  object  denoted  by  io.  In  this 
metaphor,  a  message  is  an  operation  symbol  together  with  the  remaining  arguments. 

Generic  invocation  can  be  thought  of  as  a  dynamic  form  of  overloading,  but  it  should 
not  be  confused  with  static  (i.e.,  compile-time)  overloading,  as  found,  for  example,  in  Ada 
[Ada83].  In  an  Ada  program,  both  IO_Stream  and  Text-Window  can  have  operations 
named  read-line.  However,  the  procedure  that  is  called  by  read-line  (io)  in  Ada 
depends  statically  on  the  type  of  the  variable  io  instead  of  depending  dynamically  on 
the  type  of  the  object  bound  to  io.  Since  in  Ada  the  same  variable  cannot  refer  to 

Figure  1.1:  Example  of  generic  invocation. 

var  io:  lO-Stream  :=  create (Text-Window,  ...); 
ans:  String  :=  read-line(io)  ; 
io  :®  if  (ans  =  "y") 

then  create(Text_Window,  ...) 
else  create (lO-Stream,  ...) 
end  if; 

1:  String  :=  read-line(io) 
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instances  of  different  types,  syntactically  different  invocations  would  be  needed  to  call 
each  of  the  two  read-line  operations. 

Trellis/Owl,  like  Smalltalk-80,  treats  all  invocations  of  operations  that  occur  in  a 
program  as  generic  invocations.  An  invocation  such  as  create(Text_Window,, . .)  is  a 
generic  invocation  that  takes  the  Text-Window  class  object  and  some  other  arguments 
and  returns  an  instance  of  Text-Window.  (A  class  object  is  an  object  that  represents 
a  type  at  run-time.)  Since  create  takes  a  class  object  as  an  argument,  it  is  a  class 
operation.  Operations  that  do  not  take  class  objects  as  arguments,  such  as  read-line, 
are  called  instance  operations. 

1.2  Inclusion  Polymorphism 

By  using  generic  invocation,  one  can  write  polymorphic  procedures;  that  is,  procedures 
that  can  be  applied  to  instances  of  different  types.  For  example,  the  Trellis/Owl  pro¬ 
cedure  sumFirst  in  Figure  1.2  is  polymorphic.  This  polymorphism  is  exhibited  by  the 
call. 


sumFirst (maJce(IntPair ,  1,2),  maice(IntTriple ,4 ,5 , 6) ) , 

whose  result  is  5.  IntPair  is  a  type  with  a  class  operation  make  and  instance  operations 
first  and  second.  The  type  IntTriple  also  has  an  instance  operation  named  first,  as 
well  as  a  class  operation  maJce  and  instance  operations  second  and  third.  Since  we  can 
pass  to  sumFirst  instances  of  either  IntPair  or  IntTriple,  sumFirst  is  polymorphic. 

Cardelli  and  Wegner  have  coined  the  term  inclusion  polymorphism  for  the  kind  of 
polymorphism  exhibited  by  sumFirst  [CW85,  Page  475].  Unlike  other  kinds  of  polymor¬ 
phism,  inclusion  polymorphism  implicitly  associates  a  set  of  named  instance  operations 
with  each  object.  For  example,  Trellis/Owl  implicitly  associates  the  instance  operations 
first  and  second  with  each  instance  of  IntPair. 

Figure  1.2:  Implementation  of  the  function  sumFirst  in  Trellis/Owl. 

proc  sumFirst (pi ,p2 :  IntPair)  returns (Int) 
return (add (first (pi) ,f irst (p2)) ) 


end; 
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By  contrast,  consider  writing  sumFirst  in  a  language  with  parametric  polymorphism, 
such  as  ML  [GM\V79].  In  ML  we  would  have  to  explicitly  pa^s  the  operations  that 
extract  the  first  components  of  the  objects,  because  an  object’s  instance  operations  are 
not  available  at  run-time  in  ML.  (See  Figure  1.3.)  However,  the  ML  version  of  sumFirst 
is  more  general  than  the  Trellis/Owl  version,  because  the  first  two  arguments  do  not  have 
to  be  instances  of  types  that  have  operations  named  first. 

Inclusion  polymorphism  has  two  main  advantages. 

First,  programs  may  be  more  terse  than  in  a  language  with  parametric  polymor¬ 
phism,  since  instance  operations  are  implicitly  associated  with  objects,  and  thus  extra 
parameters  for  types  or  operations  need  not  be  mentioned. 

Second,  the  type  of  a  polymorphic  procedure  mentions  the  names  of  existing  types. 
For  example,  the  declared  type  of  the  Trellis/Owl  version  of  sumFirst  is 

IntPair,  IntPair  — »•  Int, 

which  means  that  all  types  that  are  subtypes  of  IntPair  (such  as  IntTriple)  can  be 
used  as  arguments.  The  type  of  the  ML  version  of  sumFirst,  which  is 

T1,T2,(T1  Int),(T2  Int)  Int 

for  all  types  T1  and  T2,  does  not  mention  existing  types  such  as  IntPair.  One  advantage 
of  mentioning  existing  types  is  that  the  type  system  can  check  that  each  argument  has 
a  type  that  is  a  subtype  of  the  corresponding  formal  argument  type.  We  will  show  later 
how  this  property  can  be  used  in  program  verification.  In  ML,  the  type  system  does 
not  have  such  semantic  information  about  types  and  cannot  aid  one’s  verification  to  the 
same  extent  as  in  Trellis/Owl. 

Figure  1.3:  Implementation  of  the  function  sumFirst  in  ML. 

val  sumFirst (pi ,p2,firstl ,first2)  ® 
firstl(pl)  +  first2(p2) 
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1.3  Specification  and  Verification  Problems 

In  this  section  we  describe  the  problem  that  we  address  in  this  dissertation:  how  to 
specify  and  verify  programs  that  use  inclusion  polymorphism. 

Conventional  specification  techniques  are  poorly  matched  to  programs  and  functions 
that  use  inclusion  polymorphism,  because  they  do  not  exploit  the  implicit  eissociation  of 
instance  operations  with  objects. 

We  want  to  specify  functions  that  use  inclusion  polymorphism  in  a  way  that  parallels 
code  that  uses  inclusion  polymorphism.  For  example,  the  specification  in  Figure  1.4 
corresponds  closely  to  the  Trellis/Owl  code  for  sumFirst  given  above,  since  it  is  written 
as  if  all  arguments  must  have  type  IntPair.  But  we  also  allow  instances  of  subtypes  of 
IntPair,  such  as  IntTriple,  to  be  passed  as  arguments. 

The  effect  of  sumFirst  is  described  in  Figure  1.4  using  terms  that  are  tailored  to  the 
type  IntPair.  That  is,  we  think  of  the  abstract  value  of  an  IntPair  as  a  pair  of  integers. 
A  set  of  abstract  values  is  described  by  functions,  such  as  the  pairing  function  and 
the  postfixed  function  “.first,”  which  returns  the  first  component  of  a  pair. 

However,  when  the  arguments  have  type  IntTriple,  there  is  a  problem  understanding 
the  description  of  the  effect  of  sumFirst.  To  illustrate  this  problem,  we  describe  the  ab¬ 
stract  values  of  IntTriple  as  sequences  of  three  integers,  such  as  (4,5,6),  with  postfixed 
selector  functions  “[1],”  “[2],”  and  “[3].”  Consider  the  following  call  to  sumFirst: 

sumFirst(m2Lke(IntPair,  1,2) ,  make(IntTriple,4,5,6)). 

The  abstract  value  of  madte(IntTriple,4,5,6)  is  the  sequence  (4,5,6).  However,  since 
the  specification  of  sumFirst  uses  the  type  IntPair,  we  cannot  describe  the  result  by 
substituting  the  abstract  value  (4,5,6)  into  the  description  of  the  effect  of  sumFirst,  as 
the  term  “(4, 5,6).first”  is  meaningless  (since  we  can  only  apply  “.first”  to  the  abstract 
values  of  IntPair). 

Figure  1.4:  Specification  of  the  function  sumFirst. 

fun  sumFirst(pl,p2:  IntPair)  returns(i:Int) 
effect  i  =  pi. first  -|-  p2. first 
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To  give  a  formal  semantics  to  specifications  that  allows  arguments  of  all  subtypes  of 
the  specified  formal  argument  types,  we  must  also  have  a  formal  definition  of  when  one 
abstract  type  is  a  subtype  of  another. 

Of  the  formal  definitions  of  “subtype”  that  have  appeared  in  the  literature^,  only  the 
work  of  Bruce  and  Wegner  [BW87]  has  a  definition  of  subtyping  among  abstract  data 
types.  However,  Bruce  and  Wegner’s  definitions  do  not  handle  incompletely  specified 
and  nondeterministic  types,  both  of  which  are  important  in  practical  use.  (We  discuss 
Bruce  and  Wegner’s  work  and  the  work  of  others  in  more  detail  in  Chapter  5.) 

Conventional  techniques  for  program  verification  also  need  to  be  adapted  for  verifying 
programs  that  use  inclusion  polymorphism.  One  problem  is  illustrated  by  our  difficulties 
reasoning  about  the  call  to  sumFirst  above;  that  is,  we  need  a  way  to  coerce  the  abstract 
value  of  a  subtype  into  an  abstract  value  of  its  supertypes.  Another  verification  problem 
arises  because  often  we  only  know  that  an  expression  of  a  given  type  T  denotes  an  instance 
of  some  subtype  of  T.  We  must  ensure  that  reasoning  about  such  expressions  as  if  they 
denoted  instances  of  type  T  does  not  lead  to  invalid  conclusions. 

1.4  Overview  of  Our  Solution 

Our  ideas  for  solving  the  specification  and  verification  problems  described  in  the  previous 
section  are  based  on  concepts  used  by  programmers  working  in  languages  with  generic 
invocation  mechanisms.  We  simplify  the  problem  by  only  dealing  with  an  applicative 
programming  language  and  with  immutable  types.  (An  immutable  type  is  an  abstract 
type  whose  instances  have  no  time- varying  state.) 

The  fundamental  concept  is  the  notion  of  a  subtype.  Informally,  each  instance  of 
a  subtype  behaves  like  some  instance  of  its  supertypes.  To  formalize  this  notion,  we 
formalize  the  implicit  notions  of  “type”  and  “behavior.” 

Abstract  types  are  described  by  specifications.  The  implementations  of  type  specifi¬ 
cations  are  formally  modeled  with  a  family  of  algebras. 

The  behavior  of  am  instance  is  determined  by  the  way  it  affects  the  output  of  code 
run  in  an  environment  that  binds  the  instance  to  some  identifier  used  in  that  code.  Since 
instances  can  interact,  we  speak  of  the  behavior  of  the  environment  itself,  and  how  it 

‘A  survey  can  be  found  in  [DT88]. 
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affects  the  output  of  code  that  uses  the  identifiers  defined  by  the  environment.  The  formal 
model  of  such  code  is  called  an  observation.  For  example,  sumFirst  (pi  ,p2)  defines  an 
observation  on  environments  where  pi  :  IntPair  and  p2  :  IntPair  are  defined. 

We  say  that  one  environment  imitates  another  when  the  first  environment  behaves 
like  the  second,  with  respect  to  each  observation  of  interest.  For  example,  an  environment 
Tji  such  that  »7i(p2)  is  an  IntTriple  with  abstract  value  (4,5,6)  imitates  an  environment 
r/2,  where  J72(p2)  is  an  IntPair  with  abstract  value  (4,5)  with  respect  to  the  set  of 
observations  defined  by  first (p2)  and  second (p2). 

We  use  imitation  to  evaluate  the  assertions  in  specifications  as  follows.  We  eissume 
that  we  can  evaluate  assertions  in  an  environment  where  for  each  type  T,  each  identifier  of 
type  T  denotes  an  instance  of  type  T.  We  call  such  an  environment  a  nominal  environment. 
To  evaluate  an  assertion  in  an  environment  that  is  not  nominal,  one  finds  a  nominal 
environment  that  the  first  environment  imitates  and  then  evaluates  the  assertion  in  the 
nominal  environment.  For  example,  the  assertion  “p2.first  =  4”  holds  in  the  environment 
Tji  described  above,  because  rji  imitates  the  nominal  environment  described  above,  and 
in  t)2  “p2.first”  is  4. 

We  define  subtyping  so  that  one  can  always  evaluate  the  assertions  in  our  speci¬ 
fications.  Since  our  specifications  only  allow  instances  of  subtypes  as  arguments,  the 
environments  created  by  binding  the  actual  arguments  to  the  formals  are  such  that  each 
identifier  of  some  type  T  denotes  an  object  of  some  subtype  of  T.  Our  definition  of  sub¬ 
typing  ensures  that  each  such  environment  imitates  some  nominal  environment.  Since 
one  can  always  find  a  nominal  environment,  one  can  always  evaluate  the  assertions  in  our 
specifications.  For  example,  one  can  pass  arguments  of  type  IntTriple  to  sumFirst,  be¬ 
cause  one  can  always  find  instances  of  IntPair  that  the  instances  of  IntTriple  imitate. 

We  can  prove  subtype  relationships  by  showing  that  every  instance  of  each  subtype 
simulates  some  instance  of  its  supertypes.  Simulation  is  preserved  by  each  generic  invoca¬ 
tion,  whereas  imitation  is  only  guaranteed  to  preserve  externally  observable  behavior.  For 
example,  an  instance  of  IntTriple  whose  abstract  value  is  (4,5,6)  simulates  an  instance 
of  IntPair  whose  abstract  value  is  (4,5),  since  the  result  of  applying  the  operations 
first  and  second  to  the  IntTriple  simulate  the  results  of  applying  these  operations  to 
the  IntPair.  (For  the  built-in  types  like  Int,  simulation  means  equality.) 
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We  use  simulation  relationships  during  program  verification  to  translate  the  abstract 
values  of  a  subtype  into  the  abstract  values  of  a  supertype.  For  example,  to  find  the 
effect  of 

sumFirst(meLke(IntPair,l,2) ,  niaike(IntTriple,4,5,6)), 

one  proceeds  as  follows.  The  abstract  value  of  make(IntTriple,4,5,6)  is  the  sequence 
(4, 5, 6).  This  instance  simulates  an  instance  of  IntPair  whose  abstract  value  is  (4, 5),  so 
one  takes  (4, 5)  as  the  abstract  value  of  the  actual.  One  can  then  substitute  the  abstract 
values  of  the  actuals  into  the  description  of  the  effect,  obtaining 

i  =  (1,2). first  +  (4, 5). first 
which  can  be  simplified  to  “i  =  5.” 

In  the  rest  of  this  dissertation  we  not  only  work  out  the  above  solution  in  detail, 
but  we  also  show  how  to  treat  more  interesting  examples.  In  particular,  we  show  how 
to  handle  incompletely  specified  and  nondeterministic  types.  Incomplete  specifications 
are  important,  because  they  allow  a  designer  to  leave  implementation  decisions  open. 
Nondeterminism  is  important  for  some  applications  and  also  can  be  used  to  leave  imple¬ 
mentation  decisions  open. 

1.5  Plan  of  the  Dissertation 

In  this  section  we  describe  where  the  above  concepts  are  discussed  in  this  dissertation. 

Chapters  2  and  3  provide  context  and  background.  In  Chapter  2  we  describe  algebraic 
models  of  specifications  and  specifications  for  abstract  types.  In  Chapter  3  we  describe 
observations  and  how  they  are  described  by  a  programming  language  with  a  generic 
invocation  mechanism. 

In  Chapter  4  we  describe  a  technique  for  the  specification  of  functions  and  programs 
that  use  inclusion  polymorphism.  A  formal  semantics  of  such  specifications  is  given  that 
uses  the  “imitates”  relation  between  environments. 

In  Chapter  5  we  give  a  formal  definition  of  subtype  relationships.  We  show  that  this 
definition  ensures  that  the  specifications  described  in  Chapter  5  are  sensible. 

In  Chapter  6  we  give  a  formal  definition  of  simulation.  We  show  how  to  use  simulation 
relationships  to  prove  subtype  relationships. 
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In  Chapter  7  we  show  how  simulation  can  be  used  in  program  verification.  Simulation 
relationships  are  used  to  translate  assertions  from  subtypes  to  supertypes.  These  trans¬ 
lations  are  used  in  a  Hoai'e-style  proof  system  for  the  applicative  language  introduced  in 
Chapter  3. 

In  Chapter  8  we  discuss  how  our  results  can  be  applied  in  other  programming  lan¬ 
guages;  we  also  discuss  extensions  and  future  work.  In  Chapter  9  we  offer  a  summary 
and  some  conclusions.  In  particular,  we  discuss  lessons  for  programmers  and  language 
designers. 

In  Appendix  A  we  summarize  the  notation  and  definitions  introduced  throughout 
the  dissertation.  In  Appendix  B  we  describe  the  built-in  types  of  the  type  specifications 
described  in  Chapter  2.  In  Appendix  C  we  give  the  semantics  of  the  recursively-defined 
functions  of  the  programming  language  described  in  Chapter  3;  we  also  show  that  these 
functions  preserve  simulation  relationships. 

i 


Chapter  2 

Algebraic  Models  of  Type  Specifications 


The  primary  purpose  of  this  chapter  is  to  define  the  semantics  of  immutable  type  spec¬ 
ifications,  for  use  in  our  definition  of  subtype  relations.  We  take  a  “loose”  view  of  type 
specifications;  that  is,  the  semantics  of  a  type  specification  is  a  set  of  algebraic  mod¬ 
els.  We  also  describe  a  specification  language  that  we  use  in  examples  and  for  program 
verification. 

In  what  follows  we  first  define  algebras.  We  then  describe  our  specification  language 
and  its  semantics.  Afterwards  we  discuss  how  nondeterminism  and  exceptions  are  han¬ 
dled. 


2.1  Algebras 

We  use  algebras  to  model  specifications  of  immutable  abstract  types.  Our  algebras 
are  an  extension  of  the  relational  structures  studied  by  Nipkow  [Nip86]  [Nip87].  These 
structures  consist  of  a  carrier  set  for  each  type  and  a  set  of  nondeterministic  operations. 
To  Nipkow’s  relational  structures  we  have  added  functions,  called  trait  functions,  that 
aid  in  the  evaluation  of  assertions  [Win83,  Chapter  2].  As  we  explain  algebras,  we  point 
out  some  differences  from  Nipkow’s  notation. 

The  operations  of  an  algebra  are  abstractions  of  the  procedures  of  the  classes  that 
implement  abstract  types  in  object-oriented  programs.  To  model  nondeterministic  pro¬ 
cedures,  the  operations  of  an  algebra  are  set- valued  functions.  That  is,  an  operation  of  an 
cilgebra  returns  the  set  of  the  possible  results  of  the  corresponding  procedure.  To  model 
procedure  calls  that  do  not  halt  or  that  encounter  run-time  errors,  we  use  the  special 
value  ±.  So  a  procedure  that  might  either  return  1  or  never  halt  on  some  argument 
q  would  be  modeled  by  an  operation  that,  when  called  with  q,  has  {1,-L}  as  its  set  of 
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possible  results. 

The  operations  of  an  algebra  are  named  by  operation  symbols  of  the  form  The 

signatures  used  as  subscripts  on  the  operation  symbols  list  the  types  of  the  arguments 
and  the  type  of  the  result  for  the  algebra’s  operation.  Unlike  the  procedures  of  a  cleiss, 
which  may  be  polymorphic  if  they  use  generic  invocation,  the  operations  of  an  algebra  are 
not  polymorphic.  We  model  a  generic  invocation  by  subscripting  the  generic  operation 
symbol  used  in  a  program  (e.g.,  g)  with  the  types  of  the  actual  arguments,  and  consulting 
the  appropriate  operation  of  the  algebra  to  find  the  set  of  possible  results  (see  Chapter  3 
for  details).  While  it  might  be  more  elegant  to  have  algebras  model  generic  invocation, 
we  chose  to  model  generic  invocation  in  the  semantics  of  our  programming  language,  so 
that  our  algebraic  models  of  type  specifications  more  closely  resemble  standard  algebras. 

In  addition  to  its  operations,  an  algebra  also  htis  a  set  of  trait  functions.  These 
functions  have  no  counterpart  in  the  classes  that  implement  abstract  types.  The  trait 
functions  are  specified  by  traits,  which  are  descriptions  of  sets  of  abstract  values  [GH86b], 
called  sorts. 

In  our  formal  models,  we  do  not  have  separate  representations  for  abstract  values  and 
for  objects.  That  is,  we  identify  the  objects  of  a  type  with  their  abstract  values.  So  each 
type  symbol  is  also  the  name  of  a  sort.  Since  some  sorts  are  described  using  other  sorts, 
in  general  there  may  be  more  sorts  than  there  are  types. 

There  is  a  small  set  of  types  in  an  algebra  called  the  visible  types.  These  types,  such 
as  Bool  and  Int,  are  used  to  define  observations. 

For  each  sort  T  in  some  set  SORTS  of  sort  symbols,  an  algebra  A  has  a  set,  At,  called 
the  cairier  set  of  T.  If  9  €  Aj,  then  we  say  that  q  has  sort  T;  furthermore,  if  T  is  also 
type,  we  say  that  q  has  type  T  or  that  q  is  an  instance  of  type  T.  An  element  of  a  carrier 
set,  often  written  o,  q,  or  r,  is  also  called  an  object.  Each  sort’s  carrier  set  contains  the 
element  ±.  An  element  of  a  carrier  set  is  called  proper  if  it  is  not  ±.  So  that  each  proper 
object  has  only  one  sort,  the  carrier  sets  of  an  algebra  must  be  disjoint,  except  that  ± 
is  in  each  of  them.  So  the  carrier  set  of  an  algebra  A,  written  |A1,  is  a  family  of  sets 
indexed  by  sort  symbols,  that  are  disjoint  except  that  each  contains  -L.  The  family  of 
carrier  sets  indexed  by  type  symbols  is  written  Atypes- 

An  I-indexed  set  is  a  surjective  function  from  an  index  set  /  to  the  elements  of  a  set. 
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For  example,  Atypes  is  a  TYPES-indexed  family  of  sets,  since 

Atypes  =  {>It  I  T  G  TYPES}.  (2.1) 

An  operation  on  a  carrier  set  is  a  mapping  that  takes  a  tuple  of  zero  or  more  elements 
of  a  carrier  set  and  returns  a  nonempty  set  of  possible  results.  A  possible  result  is  simply 
an  element  of  a  carrier  set.  We  also  regard  operations  as  binary  relations,  where  the  set 
of  possible  results  of  an  application  of  a  binary  relation  /  to  a  tuple  of  arguments  q  is 

/(fl  =  {r|(?,r)€/}.  (2.2) 

As  above,  we  often  use  vector  notation  for  tuples.  For  example,  the  notation  q  stands 
for  a  n-tuple  {qi, . . .  ,7„},  where  n  >  0.  We  say  that  q  has  type  S,  written  q  G  Ag,  if 
each  qi  has  type  S,.  The  notation  Ag  stands  for  As,  x  ■  •  •  x  As„,  where  if  S  =  (),  then 
Ag  *=  {()}.  The  same  notation  is  also  used  for  sorts. 

Each  operation  in  an  algebra  has  a  name  and  a  signature.  If  TYPES  is  a  set  of  type 
symbols,  then  an  element  of  {TYPES*  x  TYPES)  is  called  a  signature  and  is  written  as 
— ►  T  or  Si, . . . ,  S„  — »  T  or  S  — ♦  T.  An  operation  symbol  has  its  signature  as  a  subscript,  for 
example,  gg_i-  A  family  of  typed  operation  symbols  is  a  {TYPES*  x  TYPES)Andexed 
family  of  sets.  If  OPS  is  a  family  of  typed  operation  symbols,  then  we  abbreviate  the 
statement  that  gg_i.  is  an  element  of  C>P5g_j  by  writing  gg_»x  :  S  — »  T. 

A  set  of  typed  operations  on  Atypes  is  a  set  of  operations  indexed  by  a  family  of 
typed  operation  symbols,  with  the  following  property:  for  each  operation  Agg  ^  and  for 
each  tuple  q  G  Ag,  Agg  is  a  nonempty  subset  of  At- 

A  function  (or  operation)  is  strict  if  whenever  one  of  its  arguments  is  ±,  then  the 
(only  possible)  result  is  J..  A  function  (or  operation)  is  total  if  whenever  all  its  arguments 
are  proper  (i.e.,  not  J.),  then  no  (possible)  result  is  ±.  A  function  (or  operation)  that  is 
not  total  is  partial. 

A  trait  function  is  a  strict  and  total  mapping  that  takes  a  tuple  of  zero  or  more 
elements  of  a  carrier  set  and  returns  an  element  of  the  carrier  set. 

A  family  of  sorted  trait  function  symbols  is  a  {SORTS*  x  SO  RTS  )-'indexed  set. 

A  set  of  sorted  trait  functions  on  |Al,  is  a  set  of  trait  functions  indexed  by  a  family 
of  sorted  trait  function  symbols  with  the  following  property:  for  each  trait  function 
Af  :  S  — >  T  and  for  each  tuple  q  G  Ag,  Af(f/)  G  Ay. 
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Definition  2.1.1  (algebra).  An  algebra  A  =  {\A\,  Atypes,  Atfunsi  ■^ops)i  consists  of; 

•  a  carrier  set,  |A|, 

•  a  family  of  carrier  sets  for  each  type,  Atypes-, 

•  a  set,  Ajeuns,  of  sorted  trait  functions  on  jA],  and 

•  a  set,  Aops,  of  typed  operations  on  Atypes- 

Besides  the  addition  of  trait  functions,  our  algebrtis  differ  from  Nipkow’s  because 
Nipkow  does  not  use  ±  to  represent  nontermination.  Instead  Nipkow  describes  each 
operation  by  a  binary  relation  giving  its  input/output  behavior  for  proper  elements  and 
a  termination  set  that  describes  the  inputs  for  which  termination  is  guaranteed.  As 
Nipkow  suggests,  we  can  translate  from  his  notation  into  ours  [Nip87,  Page  9].  However, 
the  operations  of  our  algebras  can  be  non-strict,  while  the  operations  of  Nipkow’s  algebras 
must  be  strict.  Non-strict  operations  are  useful  for  modeling  types  with  lazy  evaluation, 
such  as  streams. 

We  classify  operations  and  algebras  as  follows  [Nip87,  Page  9].  If  an  application  of  an 
operation  has  a  single  possible  result,  it  is  deterministic.  An  operation  is  deterministic  if 
all  applications  of  that  operation  are  deterministic.  An  operation  that  is  not  deterministic 
is  nondeterministic.  An  algebra  is  total  or  deterministic  if  all  its  operations  have  that 
property.  An  algebra  is  partial  or  nondeterministic  if  some  of  its  operations  are  partial 
or  nondeterministic. 

An  example  algebra,  B,  is  presented  in  Figure  2.1  (on  page  26).  The  figure  first 
defines  the  carrier  sets  for  each  type,  then  the  trait  functions,  and  finally  the  possible 
results  of  the  operations.  The  carrier  set  for  the  type  Bool  contains  ±,  tme  and  false. 
The  only  proper  element  of  the  carrier  set  for  BoolClass  is  Bool,  which  is  used  like  a 
class  object  in  an  object-oriented  language.  The  trait  functions  symbols  contain  sharp 
signs  (^)  as  place  holders  for  arguments,  allowing  prefix  and  infix  syntax  for  invocations. 
The  operations  themselves  include  the  nullary  operation  named  Bool_Booicia»s  which 
hcis  the  “clciss  object”  Bool  as  its  only  possible  result,  class  operations  for  true  and  false, 
and  instance  operations  for  the  usual  logical  operations.  We  abbreviate  the  description 
of  trait  functions  and  operations  by  the  following  conventions. 


•  A  vaiiable  such  as  b  only  stands  for  a  proper  element  of  the  appropriate  carrier  set, 
never  for  ±. 

•  The  only  omitted  cases  involve  X  as  an  argument,  and  for  these  the  only  possible 
result  is  X. 

•  The  trait  functions  are  used  to  define  the  operations. 

Notice  that  all  the  operations  of  B  in  Figure  2.1  are  strict,  total,  and  deterministic. 
Hence  5  is  a  total  and  deterministic  algebra. 

Each  algebra  has  a  signature,  which  is  defined  below.  Following  Nipkow,  we  include 
in  the  signature  a  set  of  visible  types,  which  are  used  to  define  observations. 

Definition  2.1.2  (signature).  \i  A  —  {\A\,  Atypesi  Atfunsi  Aops)  is  an  algebra,  then 
its  signature,  SIG{A)  =  (SORTS,  TYPES,  V,  TFUNS,  OPS),  consists  of: 

•  the  set,  SORTS,  of  sort  symbols  that  index  the  carrier  set  of  A, 

•  a  nonempty  set,  TYPES  C  SORTS,  of  the  type  symbols  that  index  AtypeS', 

•  a  nonempty  set,  V  C  TYPES  of  visible  types, 

•  the  set,  TFUNS,  of  sorted  trait  function  symbols  that  index  the  trait  functions  of 
A,  and 

•  the  set,  OPS,  of  typed  operation  symbols  that  index  the  operations  of  A. 

In  other  chapters  we  often  abbreviate  signatures  by  omitting  the  set  of  sort  symbols 

SORTS. 

If  SIG{A)  =  S,  then  A  is  a  Y,-algebra.  We  call 

E'  =  (SORTS',  TYPES',  V,  TFUNS',  OPS') 

a  subsignature  of 

E  =  (SORTS,  TYPES,  V,  TFUNS,  OPS) 

if  SORTS'  C  SORTS,  TYPES'  C  TYPES,  V  C  V,  TFUNS'  C  TFUNS,  and  OPS'  C 
OPS  [EM85,  Section  6.8].  By  TFUNS'  C  TFUNS,  we  mean  that  the  subset  relationship 
holds  at  each  index. 
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Figure  2.1:  An  algebra  B  for  the  Booleans, 
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Let  EV  =  {V,V,  V,  TFUNS  v,OPSv)  be  a  fixed  signature  for  the  visible  types. 
If  EF  is  a  subsignature  of  SIG{A)  =  {SORTS,  TYPES,  V,  TFUNS,OPS),  then  the 
S  V -reduct  of  A  is  the  algebra 

A  (  {At  \1€  V},{AT\Te  V}, 

-[{Atlfe  TFUNSv),{A^^^  I  gg_,T  e  OPSv] 

[EM85,  Section  6.8].  That  is,  j4(sv)  has  as  its  carrier  sets  the  carrier  sets  of  the  visible 
types  in  A  and  as  its  trait  functions  and  operations  those  named  in  E  V. 

We  assume  that  the  visible  types  and  their  semantics  axe  fixed  by  convention,  that  is, 
by  one’s  programming  or  specification  language.  This  assumption  allows  us  to  compare 
the  results  of  observations,  since  the  possible  results  of  an  observation  must  be  instances 
of  visible  types.  We  state  this  assumption  formally  as  follows.  Let  B  be  a  fixed  algebra 
whose  signature  is  E  V.  Formally,  our  assumption  is  that  for  each  E-algebra  A,  the  fixed 
signature  E  F  is  a  subsignature  of  E,  the  set  of  visible  types  in  E  is  F  (the  same  as  in 
EF),  and  the  E  F-reduct  of  A  is  the  fixed  algebra  B.  In  the  next  section  we  describe 
this  convention  for  our  specification  language. 

The  semantics  of  a  specification  is  a  set  of  algebras  with  the  same  signature.  Each 
algebra  in  the  semantics  of  a  specification  named  SPEC  is  called  a  SPEC -algebra.  The 
following  sections  present  one  way  of  describing  such  sets. 

2.2  Type  Specifications 

In  this  section  we  describe  our  specification  language,  which  is  adapted  from  Wing’s 
interface  specification  language  for  CLU  [Win83]  [LG86,  Chapter  10]  [GHW85]  [Win87]. 
We  have  modified  Wing’s  syntax,  in  part  to  distinguish  class  operations  from  instance 
operations.  Unlike  Wing,  we  deal  only  with  immutable  types. 

For  us,  a  specification  has  the  following  goals: 

•  describing  a  set  of  algebras,  and 

•  describing  an  interface  for  programmers  that  consists  of  a  set  of  generic  operation 
symbols  and  their  nominal  signatures. 

The  algebras  we  specify  have  many  characteristics  of  Trellis/Owl  classes,  such  as  oper¬ 
ations  that  return  class  objects  and  operations  that  model  class  and  instance  operations. 


A  generic  operation  symbol  may  be  present  in  many  different  type  specifications.  We 
use  this  convention  to  support  generic  invocation.  For  example,  we  specify  first  as  an 
operation  of  both  IntPair  and  IntTriple. 

Each  of  occurrence  of  a  generic  operation  symbol  in  a  specification  is  associated  with 
a  different  nominal  signature,  which  is  a  pair  consisting  of  a  tuple  of  type  symbols  and  a 
type  symbol,  written  — >  T  or  Si, . . . ,  S„  — »  T  or  S  — >  T.  The  nominal  signatures  of  generic 
operation  symbols  are  used  in  type-checking  and  reasoning  about  programs. 

Abstractly,  a  specification  has  four  parts;  a  set  of  type  symbols,  a  binary  relation  on 
these  type  symbols,  a  set  of  traits,  and  a  specification  of  the  operations  of  a  model.  We  call 
the  binary  relation  on  types  a  presumed  subtype  relation,  since  it  should  relate  subtypes 
to  supertypes.  Each  trait  describes  the  abstract  values  of  a  type;  formally  it  specifies 
the  carrier  set  and  trait  functions  of  a  model.  (Unless  these  traits  are  unconventional, 
they  will  be  found  in  the  Larch  Shared  Language  Handbook  [GH86a].)  The  bulk  of  our 
specifications  is  taken  up  by  operation  specifications. 

An  example  specification,  named  IPT,  is  found  in  Figure  2.2.  We  will  use  the  specifica¬ 
tion  IPT  to  help  explain  our  specification  language  in  this  section.  The  trait  “ThreeSeq” 
that  describes  the  abstract  values  of  IntTriple  is  found  in  Figure  2.3. 

We  first  describe  the  syntax  of  specifications,  then  how  a  specification  determines 
the  syntactic  interfaces  of  the  algebras  in  its  semantics,  and  finally  how  a  specification 
determines  the  behavior  of  these  algebras. 

2.2.1  Type  Specification  Syntax 

The  syntax  of  type  specifications  is  given  in  Figure  2.4.  The  nonterminals  (type), 
(trait  function),  and  (identifier)  represent  type  symbols,  trait  function  symbols,  and 
generic  operation  symbols  and  other  identifiers  (respectively). 

A  specification  consists  of  a  list  of  (type  spec)s,  each  of  which  specifies  an  abstract 
type.  A  (type  spec)  has  a  type  name,  lists  of  the  generic  operation  symbols  that  name  the 
type’s  class  and  instance  operations,  a  (basis)  clause,  and  a  list  of  operation  specifications. 
The  (basis)  clause  tells  what  trait  is  used  in  the  operation  specifications.  Operations  can 
be  specified  to  be  deterministic  or  nondeterministic  by  using  either  op  or  ndop.  Each 
(op  spec)  also  lists  the  operation’s  nominal  signature. 
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Figure  2.2:  The  type  specification  IPT,  containing  IntPair  and  IntTriple. 

IntPair  immutable  type 

class  ops  [make]  instance  ops  [first,  second] 
based  on  sort  C  from  Pair  with  [Int  for  Tl,  T2] 

op  make(c:IntPairClass,  f,s:Int)  returns(p:IntPair) 
effect  p  =  (f,s) 

op  first(p:IntPair)  returns(i:Int) 
effect  i  =  p. first 

op  second(p:IntPair)  returns(i:Int) 
effect  i  =  p.second 


IntTriple  immutable  type  IntPair 

class  ops  [make]  instance  ops  [first,  second,  third] 
based  on  sort  C  from  ThreeSeq  with  [Int  for  T] 

op  make(c:IntTripleClass,  f,s,t:Int)  returns(r;IntTriple) 
effect  r  =  {f,s,t) 

op  first(t:IntTriple)  returns(i:Int) 
effect  i  =  t[l] 

op  second(t:IntTriple)  returns(i:Int) 
effect  i  =  t[2] 

op  third(t:IntTriple)  returns(i:Int) 
effect  i  =  t[3] 
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Figure  2.3;  The  trait  ThreeSeq  that  describes  the  abstract  values  of  IntTriple. 

ThreeSeq:  trait 
introduces 

(#,#,#  ):  T,T,T  C 
#[!]:  C  ^  T 
#[2]:  C  ^  T 
#[3]:  C  T 
asserts  C  generated  by 

C  partitioned  by  [  [1],  [2],  [3]  ] 
for  all  [f,s,t:  T] 

(/,'S,t)[l]  =  / 

(/,s,/)[2j  =  5 

(/,s,<}[3]  =  t 

implies  converts  [  [1],  [2],  [3]  ] 


The  behavior  of  an  operation  is  described  using  a  (requires  clause)  and  an 
(effects  clause).  These  clauses  contain  boolean  (term)s  written  using  trait  function  sym¬ 
bols,  the  formal  arguments  of  the  operation,  and  equations.  These  terms  must  sort-check 
in  the  sense  that  trait  functions  can  only  be  applied  to  terms  of  the  expected  sorts  and 
equations  are  only  allowed  between  terms  of  the  same  sort. 

In  an  (op  spec)  for  an  instance  operation  that  appears  in  the  specification  of  a  type 
named  T,  the  first  argument’s  type  must  be  specified  to  be  T.  Similarly,  the  first  argument 
of  a  class  operation  of  a  type  T  must  be  specified  to  be  TClass,  where  TClass  is  formed 
by  joining  the  suffix  Class  to  the  type  name  T. 

For  convenience,  we  define  the  following  syntactic  sugars.  An  (trait  function)  such  eis 
“f”  used  in  a  (term)  without  arguments  is  syntactic  sugar  for  “fO.”  A  declaration  such 
as  “f,s:  Int”  is  syntactic  sugar  for  the  declaration  list  “f:  Int,  s:  Int.”  Furthermore,  an 
omitted  (requires  clause)  is  syntactic  sugar  for  a  requires  clause  of  the  form  “requires 
true.”  A  syntactic  sugar  for  exceptions  is  discussed  in  the  last  section  of  this  chapter. 


2.2.2  Syntactic  Interfaces  of  Type  Specifications 

A  specification  describes  two  syntactic  interfaces.  The  first  interface  is  a  set  of  generic 
operation  symbols  and  their  nominal  signatures.  The  second  interface  is  the  signature 
of  the  algebras  that  satisfy  the  specification.  The  signature  of  the  algebras  that  satisfy 
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Figure  2.4:  Syntax  of  Specifications. 


(specification)  ::=  (type  spec  list) 

(type  spec  list)  ::=  (type  spec)  |  (type  spec  list)  (type  spec) 

(type  spec)  ::=  (type)  immutable  type 
(class  ops)  (instance  ops) 

(basis) 

(op  spec  list) 

(clfiss  ops)  ::=  (empty)  |  class  ops  [  (ident  list)  ] 

(instance  ops)  instance  ops  (  (ident  list)  ] 

(empty)  ::= 

(ident  list)  ::=  (identifier)  |  (ident  list)  ,  (identifier) 

(basis)  based  on  sort  (identifier)  from  (identifier)  (with  clause) 
(with  clause)  (empty)  |  with  [  (renaming  list)  ] 

(renaming  list)  ::=  (renaming)  |  (renaming  list)  ,  (renaming) 
(renaming)  :;=  (identifier)  for  (ident  list) 

(op  spec  list)  ::=  (op  spec)  |  (op  spec  list)  ,  (op  spec) 

(op  spec)  ::=  (op  kind)  (op  signature) 

(requires  clause)  (effect  clause) 

(op  kind)  ::=  op  |  ndop 

(op  signature)  ;:=  (identifier)  (  (decl  list)  )  returns  (  (decl)  ) 

(decl  list)  (decl)  |  (decl  list)  ,  (decl) 

(decl)  ::=  (identifier)  :  (type) 

(requires  clause)  ::=  requires  (term) 

(effect  clause)  ::=  effect  (term) 

(term)  ::=  (identifier) 

I  (trait  function)  (  (term  list)  )  |  (trait  function)  (  ) 

1  (term)  =  (term)  ]  (  (term)  ) 

(term  list)  (term)  |  (term  list)  ,  (term) 


a  specification  is  partly  determined  by  the  set  of  generic  operation  symbols  and  their 
nominal  signatures. 

The  set  of  generic  operation  symbols  of  a  specification  consists  of  the  symbols  following 
op  or  ndop  in  (op  spec)s,  all  type  symbols  that  are  not  class  types,  and  generic  operation 
symbols  for  the  visible  types.  For  example,  the  set  of  generic  operation  symbols  of 
IPT  includes  make,  first,  second,  third,  IntPair,  IntTriple,  Bool,  Int,  IntStream, 
BoolStreaim,  and  generic  operation  symbols  for  the  visible  types  such  as  true,  false, 
not,  and,  or,  add,  and  so  on. 

The  set  of  type  symbols  described  by  a  specification  consists  of  the  type  symbols 
named  at  the  beginning  of  each  (type  spec),  the  visible  types  Bool,  Int,  IntStream, 
and  BoolStreaun,  whatever  OneOf  types  are  necessary  (as  described  in  the  section  on 
exceptions  below),  and  a  class  type  for  each  of  the  types  already  mentioned,  formed  by 
adding  “Class”  as  a  suffix  to  each  of  the  other  type  symbols.  For  example,  the  set 
of  type  symbols  of  the  specification  IPT  includes  IntPair,  IntTriple,  IntPairClass, 
and  IntTripleClass,  in  addition  to  the  visible  types  and  their  associated  class  types: 
BoolClass,  IntClass,  IntStreamClass,  and  BoolStreamClass.  A  type  symbol  such  as 
IntPair  is  a  generic  operation  symbol  with  no  arguments. 

The  generic  operation  symbols  associated  with  the  visible  types  are  found  by  taking 
the  operations  associated  with  those  types  (see  Figures  2.1,  B.l,  and  B.2)  and  strip¬ 
ping  the  associated  operation  symbols  of  their  subscripted  signatures.  For  example,  in 
Figure  2.1,  the  operation  notsool-^Bool  is  defined,  which  means  that  a  generic  operation 
symbol  not  is  associated  with  Bool. 

We  summarize  the  association  of  generic  operation  symbols  and  nominal  signatures 
in  a  specification  with  a  set-valued  function,  called  a  nominal  signature  map.  It  takes  a 
generic  operation  symbol  and  returns  a  nonempty  set  of  nominal  signatures.  If  NomSig 
is  a  nominal  signature  map  and  (S  — +  T)  €  NomSig{g),  then  g  has  nominal  signature 
S  T. 

A  specification  determines  a  nominal  signature  map,  NomSig,  as  follows.  For  each 
generic  operation  symbol  of  the  specification  g,  a  nominal  signature  is  an  element  of 
NomSig{g)  if  and  only  if  either: 

•  the  nominal  signature  is  S  — >  T  and  g  is  associated  with  a  visible  type  because 
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is  a  typed  operation  symbol  from  Figure  2.1,  B.l,  B.2,  or  the  analogous  algebra  for 
BoolStream  (see  Appendix  B), 

•  the  nominal  signature  is  — >  gClass,  the  specification  includes  g  as  a  type  symbol; 
and  gClass  is  the  type  symbol  formed  by  attaching  “Class”  as  a  suffix  of  g,  or 

•  the  nominal  signature  is  S  — »  T,  and  g  is  a  class  or  instance  operation  specified  with 
operation  signature: 

(x  :  S)  returns(y  :  T). 


For  example,  if  NomSig  is  the  nominal  signature  map  of  IPX,  then  we  have: 


NomSig{not) 

AomSi5(lntPair) 

NomSig 

NomSig{first) 


{Bool  — +  Bool} 

{— » IntPairClass) 

{intPairClass,  Int,  Int  — >  IntPair, 
IntTripleClass,  Int,  Int,  Int  —*  IntPair,  } 
{IntPair  —*  Int, 

IntTriple  Int}. 


We  require  that  for  each  generic  operation  symbol  g,  the  nominal  signatures  in 
NomSig{g)  with  the  same  number  of  argument  positions  all  differ  in  their  first  argu¬ 
ment  position,  and  there  is  at  most  one  element  of  NomSig{g)  with  no  argument  types. 

The  signature,  S  =  {SORTS,  TYPES,  V ,  TFUNS,  OPS),  determined  by  a  specifica¬ 
tion  SPEC,  has  as  its  set  of  type  symbols,  TYPES,  the  set  of  type  symbols  of  SPEC, 
and  as  its  set  of  visible  types 


V  =  {Bool,  Int,  BoolStrezun,  IntStreeun}. 


(2.4) 


The  set  of  sorts  SORTS  and  the  set  of  sorted  trait  function  symbols,  TFUNS,  are  de¬ 
termined  by  the  traits  referenced  in  the  (baisis)  clauses  of  SPEC.  These  traits  introduce 
various  sorts  and  operations,  which  become  the  sorts  and  trait  function  symbols,  as  re¬ 
named  by  the  (renaming)  clause.  In  addition  to  these,  we  add  a  trait  for  each  class  type 
TClass  of  the  form 


TCl2iss:  trait 


34 


introduces  T:  — >  TClciss. 

The  sort  name  following  the  keyword  sort  in  the  specification  of  a  type  named  T  is  re¬ 
named  to  T.  The  signature  of  each  trait  function  symbol  from  a  trait  referenced  in  the 
(basis)  clause  of  the  specification  of  a  type  T  has  the  sort  name  following  the  keyword  sort 
replaced  by  T,  in  addition  to  the  other  renamings.  The  set  of  operations  OPS  is  deter¬ 
mined  by  attaching  to  each  generic  operation  symbol  g  each  subscript  from  NomSig{g). 
That  is, 

OPS  t:'  {gg^T  I  (6  e  <^0P)  A  ((S  T)  e  NomSigig))}  .  (2.5) 

For  example,  the  signature  of  an  IPT-algebra  has  operation  symbols  f  irstintpair— int 
and  f  irstjntTriple— Int?  because  first  is  a  generic  operation  symbol  and  NoTnSig{fiT3t) 
consists  of  IntPair  — >  Int  and  IntTriple  Int. 

If  SPEC  is  a  specification,  then  we  write  SIG(SPEC)  for  its  signature. 

2.2.3  Satisfaction  for  Type  Specifications 

Besides  having  the  right  signature,  to  satisfy  a  specification  an  algebra  must  satisfy  both 
the  specification’s  traits  and  its  operation  specification,  and  its  model  of  the  visible  types 
must  be  standard. 

Since  the  traits  used  in  a  specification  do  not  specify  the  operations  of  a  model,  we 
can  use  a  standard  definition  of  satisfaction  for  traits,  by  extracting  the  carrier  set  and 
trait  functions  from  an  algebra. 

Let  A  =  (|i4|,  Atypesi  Atfunsi  Aqps)  be  an  algebra.  Then  the  functional  structure  of 
A  is  formed  by  deleting  X  from  each  sort’s  carrier  set,  restricting  the  trait  functions  to 
these  domains,  and  throwing  out  Atypes  and  Aops-  The  trait  functions  are  defined  on 
carrier  sets  without  X  because  they  are  strict  and  total.  A  functional  structure  is  thus  a 
multi-sorted  algebra,  as  used  in  the  semantics  of  first-order  logic. 

We  say  that  A  satisfies  the  traits  of  a  specification  if  and  only  if  the  functional 
structure  of  A  is  a  model  of  those  traits. 

We  evaluate  the  terms  in  a  requires  clause  or  an  effects  clause  in  the  standard  way, 
using  extended  assignments.  An  assignment  is  an  map  from  a  set  of  sorted  identifiers  to 
the  carrier  set  of  an  algebra  that  maps  each  identifier  of  sort  T  to  a  proper  element  of 
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sort  T.  We  can  extend  such  an  assignment  to  an  evaluation  of  terms  whose  free  identifiers 
are  in  the  domain  of  the  assignment  by  using  the  trait  functions  of  the  algebra  in  the 
assignment’s  range  to  evaluate  trait  function  symbols  and  by  using  the  assignment  itself 
to  evaluate  free  identifiers  [EM85,  Section  1.10].  \i  r)  •.  X  —*  \A\  is  such  an  aissignment, 
we  write  rj  for  its  extension  to  a  mapping  from  terms  to  elements  of  the  carrier  set  of  A. 
For  example,  if  T){p)  =  (1,2),  and  j))  =  then 

jJlp.first]  =  v4#.first(»7(p))  =  A#.first((l,2))  =  1. 


We  further  extend  assignments  so  that 

def  J  true  if  TjlEi]  =  t}[E2] 


t)[Ei  =  E2] 


def  I 


(2.6) 


false  otherwise. 

We  assume  that  the  carrier  set  of  Bool  is  as  in  Figure  2.1  in  all  algebras;  hence  true  and 
false  are  objects  in  all  algebras. 

We  also  use  the  following  shorthand  for  adding  a  binding  to  an  assignment: 


T)[q/x]  XL  if  /  =  X  then  q  else  q{l). 


(2.7) 


Definition  2.2.1  (satisfies  for  operations).  Consider  the  following  operation  speci¬ 
fication: 

ndop  g(x  :  S)  returns(y:T) 
requires  P 
effect  Q 

where  and  P  and  Q  are  boolean  terms  such  that  the  free  identifiers  of  P  are  from  the 
Xi  :  S,  and  the  free  identifiers  of  Q  are  from  the  Xi  :  S,  and  y  :  T.  Let  X  be  the  set  of  the 
X,  :  S,.  The  operation  ^  satisfies  the  specification  of  g  given  above  if  and  only  if  for 
all  assignments  q  whose  domain  is  X  and  whose  range  is  A  types  •,  the  following  condition 
holds.  If 


q[P\  =  frue, 

then  for  all  possible  results  q  6  /Igg  ^{q{x)), 

9  7^  -L 

'fh/ylM  = 


(2.8) 


(2.9) 

(2.10) 
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Furthermore,  whenever  some  argument  to  the  operation  is  J.,  then  the  only  possible 
result  is  J.. 

We  say  a  tuple  of  proper  arguments  satisfies  the  requires  clause  “requires  P”  if 
when  T)  is  an  assignment  that  maps  the  formals  to  the  given  tuple  of  arguments,  then 
//[PJ  =  true. 

If  g  is  specified  with  op  instead  of  ndop  then  an  operation  /4gg  ^  satisfies  the  specifi¬ 
cation  of  g  with  nominal  signature  S  — ♦  T  if  in  addition  to  the  above  requirements  ^ 
has  only  one  possible  result  on  all  proper  arguments  q  that  satisfy  the  requires  clause  of 
g- 

For  example,  the  operation  defined  by 


AfirBtintpaij._Int(p) 

def 

{A#,fir.t(p)} 

(2.11) 

Afir8tintpair_Int(-L) 

(2.12) 

(where  p  is  proper)  satisfies  the  specification  of  the  first  operation  of  type  IntPair  in 
Figure  2.2,  because  for  all  assignments  rj  that  bind  some  proper  IntPair  p  to  p,  Tj[true}  = 
true.,  and  the  only  possible  result  is  A^.{ir,i(p).  This  result  is  proper  and  such  that 

i]Ii  =  p.first]  =  true.  (2.13) 

(Recall  that  an  omitted  requires  clause  is  syntactic  sugar  for  “requires  true.”) 

The  nullary  operations  that  name  class  objects  are  implicitly  specified  as  follows: 

op  T()  returns(y:TClass) 
effect  y  =  T. 

An  operation  satisfies  this  specification  if  its  only  possible  result  is  the  result 

of  At(),  which  invokes  the  trait  function  T. 

Our  model  of  the  visible  types  is  the  algebra  that  combines  Figures  2.1  (Bool),  B.l 
(Int),  and  B.2  (IntStream)  and  a  model  of  BoolStream  that  is  analogous  to  IntStream. 
These  are  discussed  in  Appendix  B. 

We  can  now  give  a  formal  definition  of  when  an  algebra  satisfies  a  specification. 

Definition  2.2.2  (satisfies).  An  algebra  A  satisfies  a  specification  SPEC  if  and  only 
if 


37 


•  SIG{A)  =  SIG{SPEC), 

•  the  functional  structure  of  A  satisfies  the  traits  of  SPEC, 

•  for  each  operation  symbol  gg_T  in  SIG{A),  ^  satisfies  the  specification  of  g 
with  nominal  signature  S  — ►  T,  and 

•  the  SIG{B)-Teduct  of  A  is  B,  where  B  is  the  algebra  described  above  that  models 
the  visible  types. 

For  example,  the  algebra  A  of  Figure  2.5  is  an  IPT-algebra;  that  is,  A  satisfies  the 
specification  IPT. 

2.3  Specifying  Nondeterministic  Types 

Nondeterministic  operations  are  useful  for  modeling  both  “undefined”  behavior  and  types 
that  are  inherently  nondeterministic.  An  example  is  the  type  Mob  specified  in  Figure  2.6. 

The  next  operation  of  Mob  has  a  non-trivial  precondition,  specified  in  its  requires 
clause.  When  the  requires  clause  is  not  satisfied,  the  set  of  possible  results  can  be  the 
entire  carrier  set  of  the  nominal  return  type.  That  is,  we  can  have  a  Mob-algebra,  B, 
whose  carrier  set  for  Mob  is  the  set  of  finite  sets  of  integers  (plus  X),  and  in  which 

=  {-L,0, 1,  — 1, . . .}.  (2.14) 

However,  we  can  also  have  Mob-algebras  in  which  next  is  more  deterministic  (i.e.,  more 
“defined”).  For  example,  we  could  have  a  Mob-algebra  B'  where 

^  nextgob-Int^^^^  ”  (2-15) 

To  allow  an  operation  to  be  nondeterministic  on  arguments  that  satisfy  its  requires 

clause,  we  must  write  ndop  instead  of  op  in  the  operation’s  specification.  For  example, 
if  B  is  the  Mob-algebra  described  above,  then  we  can  let 

5„„tgob_i„t(m)  =^m  (2.16) 

for  all  nonempty  finite  sets  of  integers  m.  Thinking  of  operations  as  relations,  the  oper¬ 
ation  ^nextgob-int  largest  relation  such  that  the  specification  is  satisfied;  the  only 

limitation  is  that  each  possible  result  must  be  an  element  of  the  argument  sot. 
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Figure  2.5:  An  IPT-algebra,  A. 

Carrier  Sets 

AintPair  =  {-!-}  U  {{hj)  \  {ij  €  Aint)  A  (ij  J-)} 

AintPairClass  {^JntPair} 

AintTriple  =  {-L}  U  {{i,j,  k)  1  {iJ,  k  G  Amt)  A  {i,j,  k  ^  ±)} 

AintTripleClass  *=  {J-i  IntTriple) 

AbooI  {±,truejalse} 


Trait  Functions 
AintPairO  =  IntPair 

A(#,#)(t,i)  =  (bi) 

A#.first((i,j))  * 

A# . second  ((j,i))  j 

AintXripieO  =  IntTriple 

A(#,#.#>(bi,fc)  = 

A#(i]({i,j,fc))  =  i 

A#[2]((i,i,fc))  =  j 

A#(3]((i,j,^))  =  k 

AbooiO 


Operations 

AmtPair_mtPairClaB-()  J  {MPair} 

AaakemtPairClass.Int.Int-IntPair^^”^^®*^’*^)  “  {(*>i)} 

AfirstintPair-Int^P)  ”j  { A#.first(p)} 

AsecondmtPaix-Int  ~ 

AmtTriple_i„,TripleClaa.()  =  {IntTriple} 

^-akei„tTripleCla».,Int,mt,Int-mtTriple(^«<^^P^^A',  J,  k)  {{iJ,  k)} 

Aiir8tintTriple-Int(^)  “ 

AsecondjntTriple-Int^^^  {A#[2](0} 

AthirdintTriple-Int(^)  “  {A#[3](0} 

^Bool^BoolClaasO  = 
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Figure  2.6:  Specification  of  the  nondeterministic  scheduler  type  Mob. 

Mob  immutable  type 

class  ops  [new]  instance  ops  [ins,  waiting?,  empty?  next] 

based  on  sort  C  from  Set  with  [Int  for  T] 

op  new(c:MobClass)  returns(m:Mob) 
effect  m  =  {} 

op  ins(m:Mob,  i:Int)  returns(r:Mob) 
effect  r  =  m  U  {i} 

op  waiting?(m:Mob,  i:Int)  returns(b:Bool) 
effect  b  =  (i  G  m) 

op  empty?(m:Mob)  returns(b:BooI) 
effect  b  =  (m  =  {}) 

ndop  next(m:Mob)  returns(i:Int) 
requires  m  {} 
effect  i  G  m 


Again,  an  operation  can  satisfy  the  specification  of  next  without  having  this  much 
nondeterminism.  For  example,  consider  an  algebra  C  that  is  the  same  as  B  above  except 
that,  for  all  nonempty  finite  sets  of  integers  m, 

{min(m)}.  (2.17) 

2.4  Specifying  Types  with  Exceptions 

Instead  of  specifying  operations  with  non-trivial  preconditions  or  arbitrarily  defining 
a  result,  we  often  wish  an  operation  to  signal  an  exception  [Goo75].  A  programming 
language  can  define  a  mechanism  to  handle  exceptions  that  arise  while  executing  an 
invocation,  as  is  done  in  CLU  [LS79]  and  Trellis/Owl.  When  we  discuss  exceptions,  we 
suppose  that  all  operations  of  an  algebra  return  DneOf  objects.  A  OneOf  object  with 
tag  normal  models  the  normal  return,  while  a  OneOf  objects  with  other  tags  model 
exceptional  results. 

A  OneOf  type  is  like  the  variant  or  discriminated  union  types  that  appear  in  some 
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Figure  2.7:  The  trait  OneOf(normal:  Int,  empty:  Null]. 

OneOf[normal:  Int,  empty:  Null]:  trait 
introduces 

make-normal:  Int  — +  NE 
make_empty:  Null  —*  NE 
has  Tag?:  NE,  Tag  — ♦  Bool 
valjiormal:  NE  — >  Int 
vaLempty:  NE  Null 
asserts  for  all  [i:  Int] 

hasTag?(make_normal(i),  normal)  =  true 
hasTag?(make-empty(nil),  empty)  =  true 
hasTag?(make_empty(nil),  normal)  =  false 
hasTag?(make_normal(t),  empty)  =  false 
valjiormal(make_normal(i))  =  i 
val^mpty(make-empty(nil))  =  nil 
exempts  for  all  [i:  Int] 

valjiormal(make_empty(nil)) 
vaLempty  ( makeaiormal(  i ) ) 


programming  languages,  such  as  CLU  (LAB*81].  The  carrier  set  and  trait  functions  as¬ 
sociated  with  OneOf  types  are  defined  as  shown  by  the  example  trait  “OneOf[normal:  Int, 
empty:  Null],”  which  is  found  in  Figure  2.7.  (The  type  Null  hjis  only  one  proper  object, 
denoted  by  the  result  of  the  trait  function  “nil”;  it  is  used  as  a  placeholder  in  OneOf 
types.  The  type  Tag  contains  proper  objects  for  each  possible  OneOf  tag.)  The  generic 
operation  symbols  for  a  OneOf  type  are  similarly  defined. 

To  explain  our  syntactic  sugar  for  specifications  that  use  exceptions,  consider  the 
specification  of  the  type  Mob2  given  in  Figure  2.8. 

We  rewrite  each  operation  specification  that  specifies  an  exception  so  that  it  returns  a 
OneOf  type  instead.  The  “normal”  return  from  an  operation  is  denoted  by  a  OneOf  object 
with  the  tag  normal.  (We  do  not  allow  normal  as  an  exception  name.)  Each  exception 
result  is  denoted  by  a  OneOf  object  with  a  tag  that  is  the  same  as  the  exception’s  name. 
Therefore  the  specification  of  next  in  Mob2  is  syntactic  sugar  for  the  specification  of 
Figure  2.9. 

All  OneOf  types  used  in  this  fashion  have  their  specification  implicitly  included  in  a 
specification  that  uses  them. 


Figure  2.8:  Specification  of  the  type  Mob2. 


Mob2  immutable  type 

class  ops  [new]  instance  ops  [ins,  waiting?,  empty?,  next] 

based  on  sort  C  from  Set  with  [Int  for  T] 

op  new(c:Mob2Class)  returns(m:Mob2) 
effect  m  =  {} 

op  ins(m:Mob2,  i:Int)  returns(r:Mob2) 
effect  r  =  m  U  {i} 

op  waiting?(m;Mob2,  i:Int)  returns(b:Bool) 
effect  b  =  (i  G  m) 

op  empty?(m:Mob2)  returns(b:Bool) 
effect  b  =  (m  =  {}) 

ndop  next(m:Mob2)  returns(i:Int)  signals(empty(Null)) 
effect  ((m  =  {})  signals  empty(nil(Null))) 

&  ((m  5^  {})  =»  i  G  m) 


Figure  2.9:  Desugared  form  of  an  exception  specification. 

ndop  next(m:Mob2)  returns(o:  OneOf[normal:  Int,  empty:  Null]) 
effect  ((m  =  {})  o  =  make-empty  (nil)) 

&  ((m  ^  {})  =»  (hasTag?(o,normal)  &  val-normal(o)  G  m)) 
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We  can  also  specify  an  operation  so  that  it  has  a  choice  between  signalling  and 
returning  a  normal  result.  (For  example,  see  Figure  5.4  on  page  95.) 


Chapter  3 

Observations  by  an  Applicative  Language 


The  purpose  of  this  chapter  is  to  give  a  formal  definition  of  observations.  Observations  are 
used  both  to  evaluate  assertions  (see  Chapter  4)  and  in  the  definition  of  subtype  relations 
(see  Chapter  5).  A  set  of  observations  characterizes  a  programming  language.  To  make 
observations  concrete  and  to  provide  a  notation  for  examples,  we  describe  an  applicative 
programming  language  and  how  it  determines  a  set  of  observations.  Our  language  NOAL 
(Nondeterministic  Object-oriented  Applicative  Language)  is  a  functional  language  based 
on  the  lambda  calculus.  We  also  use  NOAL  for  examples  when  we  discuss  program 
verification  in  Chapter  7. 

In  the  first  section  of  this  chapter,  we  define  observations.  In  the  remaining  sections, 
we  describe  NOAL  and  its  semantics. 

3.1  Observations 

We  are  interested  in  observations  with  free  identifiers.  Such  observations  are  important 
because  they  model  procedures  that  take  arguments  (existing  objects)  aind  manipulate 
them  with  generic  invocations.  These  observations  also  highlight  the  problem  of  reasoning 
about  programs  that  exploit  inclusion  polymorphism  baised  on  imprecise  information 
about  the  types  of  arguments.  That  is,  while  each  formal  argument  has  a  type,  we  only 
know  that  the  actual  argument’s  type  is  some  subtype  of  the  formal  argument’s  type. 
This  imprecise  type  information  is  characterized  by  the  types  of  the  free  identifiers  of  our 
observations. 

A  set  of  typed  identifiers  is  a  TYPES -indexed  family  of  disjoint  sets,  where  TYPES 
is  a  set  of  type  symbols.  If  A  is  a  set  of  typed  identifiers,  and  if  x  G  A't  for  some 
T  G  TYPES,  then  we  write  x:  T,  and  say  that  x  has  nominal  type  T.  If  X  and  Y  are 
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sets  of  typed  identifiers  indexed  by  the  same  set  and  if  for  each  type  T,  Xj  C  Ij,  then 
we  write  X  CY. 

We  use  environments  to  give  meaning  to  the  free  identifiers  of  an  observation. 

Definition  3.1.1  (environment).  An  environment  is  a  mapping  from  a  set  of  typed 
identifiers  to  the  carrier  set  of  an  algebra. 

We  allow  an  environment  to  map  an  identifier  x:  T  to  an  object  of  the  carrier  set  of 
an  algebra,  regardless  of  the  object’s  type,  since  this  happens  in  programs  that  exploit 
inclusion  polymorphism.  This  is  the  major  technical  difference  between  our  environments 
and  the  environments  used  in  traditional  semantics,  where  each  identifier  of  a  given 
nominal  type  is  mapped  to  an  element  of  that  type’s  carrier  set. 

For  convenience,  we  write  ENV{X,A)  for  the  set  of  all  environments  whose  domain 
is  a  set  X  of  typed  identifiers,  indexed  by  a  set  TYPES  of  type  symbols,  and  whose 
range  is  the  TYPES-indexed  family  of  carrier  sets  Atypes  of  an  algebra  A.  We  often 
bind  identifiers  in  environments  using  the  following  notation: 

rj[q/x]  *=  A/,  if  /  =  X  then  q  else  tj{1).  (3.1) 

Observations  need  both  an  environment  and  an  algebra  to  produce  a  set  of  possible 
results. 

Definition  3.1.2  (observation).  Let  X  be  a  set  of  typed  identifiers.  An  observation 
with  free  identifiers  from  A”  is  a  mapping  that  takes  an  algebra  A  and  an  environment 
from  ENV{Y,  A),  where  X  CY,  and  returns  a  set  of  possible  results  that  have  visible 
type;  that  is,  if  SIG{A)  =  {SORTS,  TYPES,  V,  TFUNS,  OPS),  then  each  possible  result 
has  some  type  T  €  V. 

We  require  that  the  possible  results  of  an  observation  have  visible  type,  because  this 
allows  us  to  use  an  observation  on  different  algebras  and  compare  the  sets  of  possible 
results.  (Recall  that  we  assume  that  the  carrier  sets  and  trait  functions  associated  with 
the  visible  types  are  the  same  in  all  algebras  we  observe.) 

In  the  next  section  we  define  a  programming  language  with  a  generic  invocation 
mechanism  that  allows  one  to  write  observations. 
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3.2  The  Programming  Language  NOAL 

The  rest  of  this  chapter  describes  the  language  NOAL,  which  is  a  hybrid  of  Trelhs/Owl 
[SCB*S6]  and  Broy’s  AMPL  [Bro86].  We  have  taken  AMPL’s  lambda  calculus  and  ex¬ 
plicit  facilities  for  nondeterminism  and  added  to  it  Trellis/Owl’s  type  system  and  generic 
invocation  mechanism.  Type  information  aids  reasoning,  but  we  give  a  meaning  to  pro¬ 
grams  regardless  uf  whether  they  are  type-safe.  Nondeterminism  is  necessary  to  make 
certain  observations  on  nondeterministic  types  [Nip86].  The  NOAL  erratic  choice  ex¬ 
pression,  1  []  2,  has  both  1  and  2  as  possible  results.  Operationally,  the  erratic  choice 
operator  picks  one  expression  at  random  and  evaluates  it.  Therefore,  if  evaluation  of 
one  expression  may  not  halt,  then  the  entire  expression  may  not  halt.  An  angelic  choice 
expression  of  the  form  Ey  V  ^2  wiU  always  halt  if  either  E\  or  E2  always  halts.  Op¬ 
erationally,  the  angelic  choice  operator  runs  both  expressions  in  parallel  and  returns  the 
first  result.  NOAL  is  a  first-order  language;  that  is  functions  are  not  objects  in  NOAL 
programs. 

NOAL  is  only  half  of  an  object-oriented  language,  since  we  do  not  provide  a  class 
mechanism  in  NOAL.  Formally,  NOAL  programs  manipulate  the  algebras  described  in 
the  previous  chapter.  That  is,  the  meaning  of  a  NOAL  program  is  an  observation.  The 
identifiers  in  a  NOAL  program  denote  elements  of  the  carrier  set  of  an  algebra.  However, 
a  NOAL  program  cannot  directly  call  the  operations  of  an  algebra;  instead  it  can  only 
make  generic  invocations.  The  set  of  possible  results  of  a  generic  invocation  is  determined 
by  consulting  the  appropriate  operation  of  an  algebra. 

The  semantics  of  NOAL  programs  makes  certain  mild  assumptions  about  algebras. 
The  exact  conditions  are  described  in  the  sections  on  generic  invocation  below  and  in 
the  section  on  domains  in  Appendix  C.  These  conditions  are  satisfied  by  the  algebraic 
models  of  most  specifications  written  in  our  specification  language.  However,  NOAL  is 
not  restricted  to  observing  models  of  our  specifications. 

i'he  type  system  of  NOAL  uses  a  nominal  signature  map  and  a  presumed  subtype 
relation  to  do  type  checking.  It  assumes  that  the  nominal  signature  map  is  like  that 
generated  by  a  specification  written  in  our  specification  language. 

In  the  rest  of  this  chapter  we  describe  NOAL’s  syntax,  generic  invocation  mechanism, 
semantics,  and  type  system. 
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Figure  3.1:  Syntax  of  NOAL. 


(program)  ::=  (expr)  \  (rec  fun  def)  (program) 

(rec  f\in  def)  ::=  fun  (fun  identifier)  (  (decl  list)  )  :  (type)  ■  (expr)  ; 

(decl  list)  ::=  (decl)  I  (decl  list)  ,  (decl) 

(decl)  ::=  (identifier)  :  (type) 

(expr)  ::=  (identifier) 

I  bottom  [  (type)  ] 

I  (generic  operation)  (  ) 

I  (generic  operation)  (  (expr  list)  ) 

(  (fun  identifier)  (  (expr  list)  ) 

1  (  (function  abstract)  )  (  (expr)  ) 

1  if  (expr)  then  (expr)  else  (expr)  fi 

1  (expr)  D  (expr) 

I  (expr)  V  (expr) 

I  isDef?  (  (expr)  ) 

1  (  (expr)  ) 

(function  abstract)  fun  (  (decl  list)  )  (expr) 

(expr  list)  (expr)  ]  (expr  list)  ,  (expr) 


3.3  NOAL  Syntax 

The  syntax  of  NOAL  is  presented  in  Figure  3.1.  The  nonterminal  (type)  denotes  a 
type  symbol,  and  (generic  operation)  denotes  a  generic  operation  symbol.  We  do  not 
further  specify  the  syntax  of  identifiers  or  function  identifiers.  However,  we  do  not  allow 
identifiers  or  function  identifiers  appearing  in  a  program  to  be  the  same  as  the  generic 
operation  symbols  used  in  that  program.  We  assume  that  isDef?  is  neither  a  function 
identifier  nor  a  generic  operation  symbol. 

We  also  use  the  following  syntactic  sugars.  We  adopt  Broy’s  notation  for  streams  by 
considering  an  expression  of  the  form  Ei  &  E2  to  be  syntactic  sugar  for  cons(E2,Ei).  A 
declaration  such  as  f ,  s :  Int  is  sugar  for  the  declaration  list  f :  Int,  s:  Int.  A  generic 
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operation  symbol  such  as  T  used  without  a  list  of  arguments  is  sugar  for  T().  We  use 
true  and  false  as  sugar  for  true  (Bool  ())  and  false(Bool())  and  we  use  1,  2,  and  so 
on  as  sugar  for  one(Int()),  add(one(Int())  ,one(Int())),  and  so  on. 

The  following  example  program  has  the  stream  (4)  as  its  only  possible  result  (when 
applied  to  an  algebra  that  includes  the  typ^  Int  and  IntStream). 

fun  suaFirst  (pi,  p2 : IntPair) : Int  ■  add(first(pl) .first (p2)) ; 
sumFirst (make ( IntPair, 1,2) ,  make(IntTriple(3,4,5)))  k  empty(IntStream) 

3.4  Generic  Invocation  in  NOAL 

In  this  section  we  explain  how  we  translate  generic  invocations  in  NOAL  into  calls  on  the 
operations  of  an  algebra  whose  signature  is  E  =  (SORTS,  TYPES,  V,  TFUNS,  OPS). 

The  translation  from  a  generic  operation  symbol  to  an  operation  symbol  is  done  by 
a  generic  invocation  mapping,  written  Generic.  This  mapping  takes  a  generic  operation 
symbol  and  the  actual  arguments  of  the  invocation  (not  the  expressions  that  denote  the 
arguments),  and  returns  an  operation  symbol  from  OPS  or  the  special  symbol  typeError. 

It  operates  by  subscripting  the  generic  operation  symbol  with  the  types  of  the  actual 
arguments,  and  then  finding  an  operation  symbol  with  the  same  actual  argument  types. 
For  example,  if  A  is  the  IPT-algebra  of  Figure  2.5,  then 

Gcnenc(first,(l,2,3))  =  f  irstmtiripie-int- 

Since  an  operation  can  only  be  applied  to  arguments  having  the  types  declared  in  the 
algebra’s  signature,  if  there  is  no  operation  symbol  that  matches  the  actual  argument 
types  exactly,  then  Generic  must  return  typeError. 

Unlike  the  generic  invocation  mechanism  of  a  programming  language  such  as 
Smalltalk-80,  the  NOAL  generic  invocation  mechanism  has  to  find  a  nonpolymorphic 
operation.  This  limitation  of  our  algebraic  models  imposes  a  restriction  on  the  algebras 
that  NOAL  programs  can  observe.  In  Smalltalk-80,  an  operation  may  return  objects  of 
a  type  that  depends  on  the  values  of  the  operation’s  arguments.  Such  a  Smalltalk-80 
operation  would  have  to  be  modeled  by  several  operations  in  one  of  our  algebras,  each 
named  by  an  operation  symbol  whose  return  type  corresponds  to  the  type  of  object  it 
can  return.  Therefore  we  assume  that  whenever  there  is  more  than  one  operation  symbol 
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with  the  same  name  except  for  the  return  type  in  its  subscript  (e.g.,  gg^jj  and  gg_»T2)’ 
then  for  each  tuple  of  actual  arguments,  no  more  than  one  of  these  operations  has  proper 
(i.e.,  non--L)  possible  results.  This  assumption  allows  Generic  to  find  the  correct  opera¬ 
tion  symbol  from  the  list  of  actual  arguments  (or  to  pick  arbitrarily  if  all  are  ±).  This 
problem  also  shows  why  Generic  needs  the  actual  arguments  and  not  just  the  types  of 
the  actual  arguments. 

To  handle  nonstrict  operations  properly,  such  as  the  cons  operation  of  BoolStream 
and  IntStream  (see  Figure  B.2),  the  generic  invocation  mapping  cannot  be  strict.  To 
handle  cons  we  must  have  for  b  €  {true,  false]  and  for  i  G  {0, 1,  —1, . . .}: 

G'encnc(cons,  ±,  6)  ConSBoolStr8aa.Bool-.BoolStrea*  (3.2) 

(jenertc(cons,  J_,  j)  =  ConSintStreeu»,Int— *IntStreaM-  (3.3) 

We  can  have  Generic  depend  on  only  some  of  its  arguments  like  this,  provided  it  always 
has  enough  information  to  make  the  necessary  choices.  Our  type  specification  language 
only  allows  one  to  specify  types  with  strict  operations.  Therefore,  for  algebraic  models 
of  specifications  written  in  our  specification  language,  the  only  nonstrict  operations  are 
the  cons  operations  of  the  types  IntStreeun  and  BoolStream. 

3.5  NOAL  Semantics 

The  meaning  of  a  program  is  an  observation,  which  is  a  mapping  from  an  algebra- 
environment  pair  to  a  set  of  possible  results.  Throughout  the  following  we  fix  a  signature 
S  =  {SORTS,  TYPES,  V,  TFUNS,  OPS)  and  a  E-algebra  A. 

3.5.1  Semantics  of  NOAL  Expressions 

In  this  section  we  give  the  semantics  of  NOAL  expressions. 

The  meaning  of  an  expression  is  described  by  the  function  M,  which  takes  an  expres¬ 
sion  with  free  identifiers  and  function  identifiers  from  a  set  X  and  returns  an  internal 
observation  with  free  identifiers  and  function  identifiers  from  X,  An  internal  observation 
is  an  observation  whose  results  need  not  have  visible  type. 

The  following  list  gives  the  denotation  of  each  recursion-free  NOAL  expression  in 
an  environment  ij  6  ENV{X ,  A).  For  convenience,  we  assume  that  rj  also  maps  typed 
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function  identifiers  to  the  denotations  of  recursively-defined  NOAL  functions. 

•  The  only  possible  result  of  an  identifier  is  its  value  in  the  environment  ij. 

M[xI{A,t})  =  {ri{x)}  (3.4) 

•  The  only  possible  result  of  an  expression  of  the  form  bottom  [  (type)  ]  is  J_.  The 
type  is  only  included  in  the  expression  to  make  type-checking  easier.  We  have,  for 
each  type  T, 

A4[bottom[T]](A,  77)  {±}  (3.5) 


•  The  possible  results  of  a  nullary  generic  operation  are  determined  by  consulting  the 
corresponding  operation. 


MVlOKA  Tj)  !  AGe«*Wc(T))()  if  Generic(T)  typeError 
I  Jit  )  /y  ^  otherwise 


(3.6) 


•  The  possible  results  of  a  generic  invocation  are  determined  by  consulting  the  algebra 
for  each  possible  argument  list. 


Mls(E')]{A,r,) 


def 


u 


A(Gener.c(g,4))(^)  if  Genenc(g,  ^  ^  typeErro. 
{±}  otherwise 


(3.7) 


•  The  possible  results  of  a  recursively  defined  function  invocation  are  determined  sim¬ 
ilarly,  except  that  the  meaning  of  the  function  identifier  is  found  in  the  environment 
V- 

M[f{£)l(/1,>,)«  U  (,(f))®  (3.8) 

f€MlS](A)(v) 

•  The  set  of  possible  results  of  a  combination  is  the  set  of  possible  results  of  the  body 
of  the  function  abstract  in  each  environment  that  extends  the  original  by  binding 
a  list  of  possible  arguments  to  the  formals. 

AflCfun  (x:S)  Eo)(^)I(A,77)  ='  U  M[Eo]iA,7j[q/i^)  (3.9) 

qiMlS]{A,Ti) 
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•  The  set  of  possible  results  for  an  if  expression  depend  on  the  possible  results  for 
the  first  subexpression. 


A^[if  E\  then  E2  else  E^  fi](i4,7/) 

(  M\E2\{A,t})  \{q  =  true 
=  U  {  M{E:X{^^n)  \iq=  false 

qeMlEi]{A,v)  [  {±}  otherwise 


(3.10) 


The  set  of  possible  results  of  an  erratic  choice  expression  includes  those  of  both 


subexpressions. 


MIE,  Q  E2](A, q)  MlEr](A,  q)  U  M[E2](A,  q)  (3.11) 


•  The  set  of  possible  results  of  an  angelic  choice  expression  is  the  same  as  an  erratic 
choice,  except  that  ±  is  a  possible  result  only  if  it  is  a  possible  result  of  both 
subexpressions. 


^  1  1.  i  M\B^\(A,ri)  (3.12) 

(  M\Ei\{A^q)\J  M\Efi\{A,q)  otherwise 

The  set  Si  \  Sj,  consists  of  the  elements  of  Sj  that  are  not  elements  of  S2* 


•  The  primitive  isDef?  can  be  used  to  see  if  an  exprecsion’s  possible  results  are 
proper. 

(3.13) 


M(isD9f?(£:)l(A>,)«  U  (  “ 


9  ^  -L 
otherwise 


Since  there  is  no  “^lssignment  statement”  the  only  way  to  bind  objects  to  identifiers 
is  through  function  calls  or  the  application  of  a  function  abstract.  The  parameter 
paissing  mechanism  of  NOAL  is  lazy  evaluation,  so  isDef  ?  is  needed  to  define  strict 
functions. 


3.5.2  Semantics  of  Recursive  Function  Definitions 

NOAL  programs  may  begin  with  a  system  of  mutually  recursive  function  definitions.  In 
the  body  of  a  recursively  defined  function,  there  can  be  no  free  identifiers  or  function 
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identifiers,  besides  those  of  the  other  recursively  defined  functions  and  the  function’s 
formal  arguments. 

Since  NOAL  “functions”  can  be  nondeterministic,  their  denotations  are  operations. 
Recall  that  an  operation  is  a  mapping  that  takes  a  tuple  of  zero  or  more  elements  of  a 
carrier  set  and  returns  a  nonempty  set  of  possible  results. 

It  is  a  difficult  problem  to  find  the  least  fixed  points  of  systems  of  mutually  recur¬ 
sive  function  definitions  in  NOAL.  We  discuss  the  construction  of  leaist  fixed  points  in 
Appendix  C.  In  this  section  we  merely  give  some  informal  explanations  and  examples. 

NOAL  uses  lazy  evaluation  for  evaluating  function  arguments  [Sch86,  Page  181]; 
Broy  calls  the  rule  call-time-choice.  Like  call-by-name,  call-time-choice  uses  delayed 
evaluation,  hence  functions  written  in  NOAL  need  not  be  strict.  However,  each  actual 
parameter  is  only  evaluated  once;  hence  formal  parameters  are  not  themselves  sources 
of  nondeterminism.  That  is,  if  a  formal  argument  is  mentioned  twice  in  the  body  of  a 
>  lambda-abstraction,  the  same  value  will  be  substituted  in  each  instance.  The  following 

program  demonstrates  the  difference  between  call-time-choice  and  call-by-name: 

fun  f  (x:Int):  Int  ■  add(x,x);  f(0  []  1). 

In  our  call-time-choice  semantics  this  program  has  as  possible  results  both  0  and  2;  a 
result  of  1  is  not  possible  with  call-time-choice,  although  it  would  be  possible  with  call- 
by-name.  Another  interesting  example  is  the  following  program: 

fun  choose (x : Int) :  Int  =  x  V  choose(add(x, 1) ) ;  choose(O). 

This  program  has  as  its  set  of  possible  results  all  positive  integers;  furthermore,  it  is 
guaranteed  to  terminate!  If  we  replaced  the  angelic  choice  (v)  with  an  erratic  choice  (Q) 
in  this  program,  the  program  would  also  have  all  positive  integers  as  possible  results,  but 
in  addition  it  might  not  terminate. 

3.5.3  Semantics  of  NOAL  Programs 

We  also  use  M  to  denote  the  function  that  takes  a  program  with  free  identifiers  from 
some  set  of  typed  identifiers,  and  returns  an  observation  with  free  identifiers  from  the 
same  set.  Consider  the  program  F;  E,  with  a  list  of  recursive  function  definitions  F,  an 
expression  E,  and  whose  free  identifiers  are  taken  from  a  set  X.  Let  t]  E  ENV(V,  A)  be 
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zui  environment,  where  X  QY.  Let  rj'  be  »?[//f],  that  is,  77  extended  by  binding  fixed 
points  f  to  the  function  identifiers  f  defined  in  F.  We  ensure  that  all  possible  results  of 
a  program  have  visible  type  using  the  following  function: 

,r.  •. ,  /  N  def  (  g  if  9  €  At  and  T  €  V  zo  1 

VMe(q)  =  I 

We  use  the  above  conventions  and  the  meaning  of  the  expression  E  to  define  the  meaning 
of  the  program  F\  E  as  follows: 

MlF-,El{A,Tj)=  Visible{MlE}{A,r}')).  (3.15) 

3.6  Nominal  Types  and  Type  Checking  for  NOAL 

Type-safe  programs  are  interesting  because  they  cam  only  observe  the  results  of  an  expres¬ 
sion  by  invoking  the  instance  operations  of  the  expression’s  nominal  type.  For  example, 
a  type-safe  program  cannot  apply  third  to  am  expression  of  nominal  type  IntPair. 
So  when  observed  by  a  type-safe  program,  instances  of  IntTriple  that  are  bound  to 
identifiers  of  nominal  type  IntPair  behave  like  instances  of  IntPair. 

We  describe  type-safe  programs  and  their  nominal  types  by  using  a  nominal  signature 
map  NomSig,  and  a  presumed  subtype  relation  <. 

To  support  inclusion  polymorphism,  if  S  <  T,  then  argument  expressions  of  nominal 
type  S  can  be  used  where  arguments  of  nominal  type  T  are  expected  [SCB*S6]. 

For  our  purposes  in  Chapter  6,  we  want  to  ensure  that  each  expression  and  program 
has  only  one  nominal  type.  Therefore,  we  assume  that  the  nominal  signature  map  NomSig 
satisfies  the  following  conditions,  for  all  generic  operation  symbols  g  in  the  domain  of 
NomSig. 

•  If  — >  T  6  NomSig(g),  then  there  is  no  other  nominal  signature  in  NomSig{g,)  that 
haii  no  argument  positions.  That  is,  there  is  at  most  one  nominal  signature  of  the 
form  -+  T  in  NomSig{g). 

•  If  S  — ►  T  6  NomSigig)  and  S  is  not  empty,  then  every  other  element  of  NomSig{g) 
with  the  same  number  of  argument  positions  differs  from  S  — ♦  T  in  at  least  the  first 
argument  position. 
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While  this  is  not  the  only  way  to  ensure  that  each  generic  invocation  expression  has 
only  one  nominal  type,  it  matches  the  nominal  signature  maps  our  specification  language 
generates.  Bruce  and  Wegner  ensure  that  each  expression  has  a  single  type  by  imposing 
a  “regularity”  condition  on  <  [BW87].  In  Cardelli’s  type  systems  (e.g.,  [Car84]),  each 
expression  has  several  types. 

Figure  3.2  shows  the  type  inference  rules  for  NOAL.  These  rules  precisely  define  the 
nominal  type  of  each  NOAL  expression.  In  the  figure,  II  is  a  set  of  type  assumptions  of 
the  form  x  :  T,  meaning  that  the  identifier  x  has  nominal  type  T,  or  f  :  S  — >  T,  meaning 
that  the  function  identifier  f  has  nominal  signature  S  — +  T.  We  also  use  vector  notation; 
X  :  S  means  that  each  x,  has  nominal  type  S,.  The  notation  H.x  :  T  means  II  extended 
with  the  assumption  x  :  T  (where  the  extension  replaces  all  assumptions  about  x  in  H). 
The  notation  II  E  •.  T  means  that  given  II  one  can  prove,  using  the  inference  rules, 
that  the  expression  E  has  nominal  type  T.  An  inference  rule  of  the  form: 

hi,h2 

c 

means  that  to  prove  the  conclusion  c  one  must  first  show  that  both  hypotheses  hi  and 
/i2  hold.  Rules  written  without  hypotheses  and  the  horizontal  line  are  axioms. 

The  only  rules  that  allow  one  to  exploit  the  presumed  subtype  relation  <  are  [ginvoc], 
[fcall]  and  [comb].  The  rules  [fcall]  and  [comb]  allow  the  nominal  type  of  an  actual 
argument  expression  to  be  a  presumed  subtype  of  the  formal’s  type.  The  rule  [ginvoc] 
is  similar,  except  that  one  must  pick  a  nominal  signature  for  the  generic  operation  such 
that  the  nominal  type  of  the  first  actual  argument  is  the  same  as  the  nominal  type  of 
the  first  formal  argument. 

We  do  type  checking  on  a  program  by  using  the  nominal  types  of  the  program’s  free 
identifiers.  Let  X  be  a  set  of  typed  identifiers  indexed  by  TYPES',  that  is,  for  each 
X  €  A,  we  associate  a  nominal  type  T  €  TYPES.  We  can  therefore  regard  X  as  a  set 
of  type  assumptions.  We  say  a  program  P  whose  set  of  free  identifiers  is  X  has  nominal 
type  T  if  we  have  A  h  P  :  T.  Since  the  syntax  of  NOAL  does  not  provide  a  way  to  declare 
the  nominal  type  of  each  free  identifier  in  a  program,  we  always  give  this  as  auxiliary 
information. 

The  set  of  type-safe  expressions  over  NomSig  and  <  is  the  set  of  all  NOAL  expressions 
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[ident] 

[fident] 

[ngop] 


Figure  3.2:  Type  Inference  Rules  for  NOAL 
/f.x  :  T  I-  X  :  T 

—y  TClass  £  NomSig{T) 

H  F  TO  :  TClass 


[ginvoc] 


S  — >  T  €  NomSig{g),  H  E  :  a,  =  Si,  <72  ^  S2, .  ■ . ,  ^  Sp 

H\-giE):T 


[fcall] 


//  I-  f  :  S  ->  T,  //  h  £  :  g,  g  <  S 
//hf(£)  :T 


[comb] 

[if] 

[erratic] 

[angelic] 


//■X  :  S  h  £0  :  To,  £  h  £  :  g,  g  <  S 
H  h  (fun  (x  :  S)  Eq)  (E)  :  To 

£  I-  £1  :  Bool,  £  h  £2  :  T,  J?  I-  £3  :  T 
£  H  (if  El  then  £2  else  £3  fi)  :  T 

£  H  £1  :  T,  £  h  £2  :  T 
£h(£,a£2):T 

£  1-  £1  :  T,  £  h  £2  :  T 


£  H  (£i  V  ^2)  :  T 
[isDef]  £  h  isDef?(£)  :  Bool 
[bol]  £  h  bottom  [T]  :  T 

f  1  :  *  Ti )  •  •  •  1  f m  •  Sn»  ^  Tm j  •  Sj  I”  Ei  :  Ti , 


[prog] 


f  1  •  Si  y  T]  ,  .  .  .  ,  f  m  :  S,n  ^  ,  Xm  :  Sm  1“  Eyn  :  T,n  > 

£.fi  :  s"i  Ti, . . .  ,f„,  :  s;;  T,n  I-  £  :  T 
/  fun  fi  (xi  :Si):Ti  »  £i ;  \ 


£1- 


(j^m  •  Snj)  "Tni  *  £l  i 

V  E 


:T 
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that  have  a  nominal  type,  when  type-checked  using  NomSig,  <  and  the  types  of  their 
free  identifiers.  The  set  of  type-safe  programs  over  NomSig  and  <  is  the  set  of  all  NOAL 
programs  whose  nominal  type  is  a  visible  type.  If  SPEC  is  a  specification  with  nominal 
signature  map  NomSig  and  presumed  subtype  relation  <,  we  write  “the  set  of  type-safe 
NOAL  programs  over  SPEC." 

The  nominal  type  of  an  expression  can  be  thought  of  as  an  upper  bound  on  the  types 
of  values  the  expression  can  denote.  That  is,  suppose  E  \s  &  type-safe  expression  over 
NomSig  and  <.  Then  the  elements  of  Ad|i?)(A,  t/)  must  be  instances  of  a  type  that  is 
related  by  <  to  E's  nominal  type,  if  <,  NomSig,  A,  and  g  meet  the  following  conditions. 
First,  <  must  be  reflexive  and  transitive.  Second,  if  S  <  T,  then  S  must  have  all  the 
instance  operations  of  T,  and  the  nominal  signatures  of  these  operations  must  be  suitably 
related.  This  condition  is  formalized  in  the  definition  of  safe  relations  below.  Third,  t) 
must  be  such  that  every  identifier  is  mapped  to  an  instance  of  some  type  that  is  related 
by  <  to  the  identifier’s  nominal  type.  This  condition  is  formalized  in  the  definition  of  an 
environment  that  obeys  a  relation  below.  Finally,  the  signature  of  A  must  be  that  of  a 
specification  with  nominal  signature  map  NomSig  and  presumed  subtype  relation  <.  In 
what  follows,  we  formalize  the  above  remarks. 

The  definition  of  safe  relations  parallels  the  syntactic  restrictions  placed  on  the  sub- 
type  relations  in  Trellis/Owl  [SCB*86]. 

Definition  3.6.1  (safe).  Let  NomSig  be  a  nominal  signature  map.  Let  GOP  be  the 
domain  of  NomSig.  Let  <  be  a  binary  relation  on  type  symbols.  Then  <  is  safe  with 
respect  to  NomSig  if  and  only  if  for  every  generic  operation  symbol  g  G  GOP  the  following 
property  holds.  If  T,  ArgTj, . . .  ,ArgT„  — »  RetT  is  an  element  of  NomSig{g),  and  S  <  T, 
then  there  must  be  some  a  nominal  signature  S,  ArgSj, . . . ,  ArgS„  — »  RetS  in  NomSig{g) 
such  that  Rets  <  RetT  and  for  all  i  from  2  to  n,  ArgT,  <  ArgS^. 

For  example,  a  relation  such  that  IntTriple  <  IntPair  is  safe  with  respect  to  the 
nominal  signature  map  of  IPT.  However,  a  relation  such  that  IntPair  <  IntTriple  is 
not  safe. 

Environments  that  obey  a  subtype  relation  are  fundamental  to  our  methods  for  spec¬ 
ification  and  verification,  as  well  as  our  definition  of  subtype  relations. 
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Definition  3.6.2  (obeys).  Let  E  =  {SORTS,  TYPES,  V,  TFUNS,  OPS)  be  a  signa¬ 
ture.  Let  X  be  a  set  of  typed  identifiers,  indexed  by  TYPES.  Let  i4  be  a  E-algebra. 
Let  <  be  a  binary  relation  on  TYPES.  Let  rj  E  ENV{X,A)  be  an  environment.  Then 
T)  obeys  <  if  and  only  if  for  every  type  T  6  TYPES  and  for  every  x  of  nominal  type  T  in 

r]{x)  has  a  type  S  such  that  S  <  T. 

Notice  that  no  environment  obeys  the  empty  relation  on  types. 

In  the  following  lemma,  we  show  that,  if,  in  addition  to  the  conditions  listed  above, 
each  recursively  defined  function  is  such  that  whenever  it  is  given  arguments  whose  types 
are  subtypes  of  the  formal  argument’s  nominal  types,  the  type  of  each  possible  result  is 
a  subtype  of  the  function’s  nominal  result  type,  then  the  nominal  type  of  an  expression 
is  an  upper  bound  on  the  types  of  the  expression’s  possible  results. 

This  lemma  is  also  the  source  of  the  conditions  on  <  listed  above.  The  condition 
that  <  be  reflexive  comes  from  expressions  such  as  T,  where  T  is  a  type  symbol,  since  the 
possible  results  of  such  an  expression  have  the  expression’s  nominal  type.  The  condition 
that  <  be  transitive  comes  from  function  calls,  where  the  nominal  type  of  a  formsil  may 
be  S,  the  nominal  type  of  the  actual  may  be  <r  <  S,  and  the  type  of  the  actual  argument 
may  be  cr'  <  a.  The  condition  that  <  be  safe  with  respect  to  the  nominad  signature 
map  comes  from  generic  invocations,  where  the  generic  invocation’s  nominal  signature 
must  be  appropriately  related  to  the  signature  of  the  operation  that  the  NOAL  generic 
invocation  mechanism  selects. 

To  handle  environments  defined  on  function  identifiers  in  the  following  lemma  we 
define  “obeys”  for  functions.  Let  A  be  an  algebra  and  let  t}  be  such  an  environment 
whose  range  is  A.  We  say  that  t/  obeys  <  if  for  each  f  :  S  — »  T  in  the  domain  of  rj, 
whenever  <?  <  S  and  q  E  Ag,  then  each  possible  result  of  has  some  type  r  <  T. 

Lemma  3.6.3.  Let  SPEC  be  a  specification.  Let  NomSig  be  the  nominal  signature 
map  of  SPEC .  Let  <  be  the  presumed  subtype  relation  of  SPEC.  Let  £"  be  a  NOAL 
expression  of  nominal  type  T  whose  set  of  free  identifiers  and  free  function  identifiers  is 
X.  Let  A  be  an  algebra  whose  signature  is  SIG{SPEC).  Let  ij  E  ENV{X,A)  be  an 
environment. 

Suppose  <  is  reflexive  and  transitive,  <  is  safe  with  respect  to  NomSig,  and  rj  obeys 
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<•  Then  each  possible  result  of  M.[E}{A,t})  has  a  type  t  <  T. 

Proof:  (by  induction  on  the  structure  of  expressions.) 

As  a  basis,  we  show  that  the  result  holds  for  identifiers,  bottom  [T],  and  nullary 
generic  operations.  If  the  expression  is  an  identifier  x  :  T,  then  A^|xJ(A,  ?/)  =  {»;(x)}  and 
by  hypothesis,  the  type  of  j/(x)  is  related  by  <  to  T.  The  result  is  trivial  for  bottom  [T], 
since  the  only  possible  result  is  JL.  The  result  is  also  trivial  for  a  nullary  generic  operation 
symbol  of  type  T,  since  <  is  reflexive  and  the  only  possible  result  has  type  T. 

For  the  inductive  step  we  assume  that  the  result  holds  for  each  subexpression. 

•  Suppose  the  expression  is  a  generic  invocation  g(.E).  By  the  type  inference  rule 

[ginvoc],  g  has  some  nominal  signature  S  — ♦  T,  .E  :  a,  ai  =  Si,  and  for  each  i  from 
2  to  n,  <  S,-.  Let  ^  be  a  tuple  of  possible  results  from  E.  By  the  inductive 
hypothesis,  q  has  a  type  a'  such  that  a'  <  B.  Since  <  is  safe  with  respect  to 
NomSig  and  <  Si,  there  is  some  nominal  signature  ctJ,  ArgSj, . . . ,  ArgS,^  — +  RetS 
in  NomSig (g)  such  that  RetS  <  T  and  for  all  i  from  2  to  n,  S<  <  ArgS,-.  By  definition 
of  S[G{SPEC),  if  for  each  i  from  2  to  n,  <r,'  =  ArgS,,  then  there  is  an  operation 
symbol  and  so  by  the  semantics  of  NOAL,  each  possible  result  has  type 

Rets  <  T.  If  there  is  no  such  operation  symbol,  then  the  only  possible  result  is  ± 
which  has  type  T. 

•  Suppose  the  expression  is  a  function  call  f(E).  By  the  type  inference  rule  [fcall],  f 
has  some  nominal  signature  S  T,  E  :  B,  and  ct  <  S.  Let  9  be  a  tuple  of  possible 
results  from  E.  By  the  inductive  hypothesis,  ^has  a  type  <7'  such  that  <7'  <  <r.  By 
hypothesis  <  is  transitive,  so  a'  <  S.  Since  tj  obeys  <,  each  possible  result  has 
some  type  r  <  T. 

•  Suppose  the  expression  is  a  combination  (fun  (x  :  S)  Eq)  (.E).  By  the  type 
inference  rule  [comb],  Eq  has  nominal  type  T,  E  :  B,  and  B  <  S.  Let  g  be  a  tuple 
of  possible  results  from  E.  By  the  inductive  hypothesis,  q  has  a  type  cr'  such  that 
a'  <  B.  By  hypothesis  <  is  transitive,  so  <7'  <  S.  So  the  environment  rj[q/x\  obeys 
<  and  thus  the  result  follows  from  the  inductive  hypothesis  applied  to  Eq. 

•  The  result  follows  directly  from  the  inductive  hypothesis  for  the  other  expressions. 
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The  following  lemma  says  that  the  possible  results  of  a  recursively  defined  function 
in  NOAL  are  related  by  <  to  the  function’s  nominal  result  type,  provided  the  conditions 
above  are  met. 

Lemma  3.6.4.  Let  SPEC  be  a  specification.  Let  NomSig  be  the  nominal  signature 
map  of  SPEC.  Let  <  be  the  presumed  subtype  relation  of  SPEC.  Let  A  be  an  algebra 
whose  signature  is  SIG{SPEC).  Let  F  he  a.  type-safe  system  of  mutually  recursive  NOAL 
function  definitions.  Let  f  be  a  function  in  F,  the  formals  of  f  be  x  :  S,  the  body  of  f 
be  the  expression  E,  and  let  f  have  nominal  signature  S  — >  T.  Let  rj  be  an  environment 
whose  domain  is  the  x,  and  whose  range  is  A. 

Suppose  <  is  reflexive  and  transitive,  and  <  is  safe  with  respect  to  NomSig,  and  77 
obeys  <.  Then  each  possible  result  of  A/{\E\{A,ri)  has  a  type  t  <  T. 

Proof:  Let  q  €  M.\E\{A,r])  be  a  possible  result.  If  g  =  X  the  result  is  trivial,  so 
suppose  q  Jl.  Pick  a  computation  that  produces  q.  Since  q  ^  ±,  the  computation 
uses  only  finitely  many  calls,  say  n,  to  the  f<.  Expand  E  by  replacing  each  call  to  a 
function  f,-  G  F  with  its  body  and  repeating  this  process  on  the  resulting  expression  n 
times  and  then  replace  all  the  remaining  function  calls  with  the  expression  bottom  [5], 
where  S  is  the  nominal  result  type  of  the  replaced  call.  This  process  does  not  change  the 
nominal  type  of  the  resulting  expression,  and  since  there  ^re  no  free  function  identifiers 
that  remain,  the  result  follows  from  the  previous  lemma.  ■ 

Since  each  recursively  defined  function  preserves  our  view  of  types  as  an  upper  bound, 
each  expression  also  preserves  that  view.  So  the  following  lemma  differs  from  Lemma  3.6.3 
in  that  no  assumption  is  made  about  the  environment’s  function  identifiers. 

Lemma  3.6.5.  Let  SPEC  be  a  specification.  Let  NomSig  be  the  nominal  signature 
map  of  SPEC.  Let  <  be  the  presumed  subtype  relation  of  SPEC.  Let  E  be  a  NOAL 
expression  of  nominal  type  T  whose  set  of  free  identifiers  is  X.  Let  A  be  an  algebra  whose 
signature  is  SIG{SPEC).  Let  7/  €  ENV{X ,A)  be  an  environment. 

Suppose  <  is  reflexive  and  transitive,  <  is  safe  with  respect  to  NomSig,  and  7/  obeys 
<.  Then  each  possible  result  of  M[Bl(A,q)  has  a  type  r  <  T. 


59 


Proof:  By  the  previous  lemma,  if  we  extend  rj  by  binding  the  denotation  of  each 
recursively  defined  function  identifier  that  is  free  in  E  to  its  denotation  in  A,  then  the 
extended  environment  obeys  <.  So  by  Lemma  3.6.3,  the  result  follows.  I 


Chapter  4 

Specifying  Polymorphic  Functions 


In  this  chapter  we  describe  a  new  method  for  the  specification  of  functions  that  exploit 
inclusion  polymorphism. 

VVe  write  specifications  as  if  each  argument  and  result  has  the  specified  type,  and  then 
allow  arguments  and  results  to  have  types  that  are  subtypes  of  the  specified  types.  Our 
specifications  follow  the  practice  of  Trellis/Owl  and  other  languages  that  allow  instances 
of  subtypes  to  be  used  wherever  instances  of  their  supertypes  can  be  used.  An  example 
is  the  specification  of  sumFirst,  found  in  Figure  1.4  on  page  15.  It  specifies  that  the 
arguments  must  be  instances  of  a  subtype  of  IntPair,  but  its  effect  is  written  using  the 
trait  functions  for  the  type  IntPair.  The  advantage  of  this  approach  is  that  the  syntax 
and  semantics  of  our  specifications  parallels  that  of  the  implementations.  However,  there 
is  no  standard  semantics  for  such  specifications  when  the  actual  arguments  do  not  have 
the  specified  types. 

We  describe  a  semantics  for  such  specifications.  We  know  how  to  evaluate  the  asser¬ 
tions  that  specify  the  effect  of  a  function  in  an  environment  where  each  formal  argument 
identifier  denotes  an  actual  argument  whose  type  is  the  same  as  the  formal’s  nominal 
type.  We  call  such  an  environment  a  nominal  environment.  To  evaluate  an  assertion 
in  an  environment  that  is  not  nominal,  one  finds  a  nominal  environment  that  the  first 
environment  imitates,  and  uses  the  nominal  environment  to  evaluate  the  assertion.  We 
define  when  one  environment  imitates  another  with  respect  to  a  set  of  observations,  al¬ 
lowing  the  first  environment  to  be  more  deterministic  with  respect  to  each  observation 
in  the  set.  We  use  this  method  for  evaluating  assertions  to  define  satisfaction  for  NOAL 
function  specifications. 

Our  semantics  is  independent  of  the  definition  of  subtype  (given  in  Chapter  5),  since 
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in  this  chapter  we  use  binary  relations  on  types  without  assumptions  about  what  such  a 
relation  means. 

After  describing  the  syntax  of  function  specifications,  we  define  evaluation  of  asser¬ 
tions  using  the  imitates  relation  and  the  semantics  of  polymorphic  function  specifications. 
We  then  discuss  the  limitations  of  our  approach,  the  problems  in  adapting  our  approach 
to  the  specification  of  types  with  polymorphic  operations,  and  why  our  semantics  for 
function  specifications  is  plausible. 

I 

I 

4.1  Syntax  of  Function  Specifications 

To  specify  NOAL  functions  we  use  syntax  similar  to  that  for  operation  specifications, 
except  that  we  use  fun  instead  of  ndop.  That  is,  we  give  an  operation  name,  a  nominal 
signature,  a  (requires  clause)  and  an  (effect  clause);  the  latter  two  contain  terms  written 
using  trait  function  symbols  (see  Figure  2.4  for  the  syntax  of  terms). 

Since  an  NOAL  program  is  applicative,  we  also  use  this  syntax  to  specify  NOAL 
programs. 

The  trait  functions  used  in  a  function  specification  must  be  taken  from  a  specification 
of  some  abstract  data  types;  we  call  the  specification  of  these  abstract  types  the  referenced 
specification.  The  referenced  specification  is  explicitly  named  in  function  specifications 
following  the  keyword  uses  (this  is  similar  to  Wing’s  specifications  [Win83],  although  we 
are  naming  a  specification  of  several  abstract  types  instead  of  a  trait). 

For  example,  a  specification  we  call  is2waiting  is  given  in  Figure  4.1.  The  referenced 
specification  is  MP,  which  specifies  the  types  Mob  (see  Figure  2.6  on  page  39)  and  PSchd 
(see  Figure  4.2). 

The  scheduler  type  PSchd  (short  for  priority  scheduler)  is  specified  in  Figure  4.2. 
(The  trait  OrderedSet  that  is  defined  below  in  Figure  4.3,  extends  the  standard  set  trait 

Figure  4.1:  The  function  specification  is2waiting. 

fun  is2waiting(m;Mob)  returns(b;Bool) 
uses  MP 
requires  true 
effect  b  =  (2  6  m) 
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Figure  4.2;  Specification  of  the  priority  scheduler  type,  PSchd. 

PSchd  immutable  type 

class  ops  [new]  instance  ops  [ins,  waiting?,  next,  empty?,  leastFirst] 

based  on  sort  C  from  Pair 

with  [Bool  for  Tl,  OrderedSet  with  [Int  for  T]  for  T2] 

op  new(c:PSchdClass,  biBool)  returns(p:PSchd) 
effect  m  =  (b,  {}) 

op  ins(p:PSchd,  i:Int)  returns(m:PSchd) 
effect  m  =  (p.first,  p. second  U  {i}) 

op  waiting?(p:PSchd,  i:Int)  returns(b:Bool) 
effect  b  =  i  €  p. second 

op  empty ?(p;PSchd)  returns(b;Bool) 
effect  b  =  (p.second  =  {}) 

op  next(p:PSchd)  returns (i: Int) 
requires  p.second  ^ 
effect  i  e  p.second 

&  (p.first  =»  lowerBound?(p.second,i)) 

&  ((-'p.first)  =»•  upperBound? (p.second,!)) 

op  leastFirst(p:PSchd)  returns(b:Bool) 
effect  b  =  p.first 


by  adding  the  trait  functions  “lowerBound?”  and  “upper Bound?”.)  The  abstract  values 
of  PSchd  instances  can  be  thought  of  as  pairs,  consisting  of  a  boolean  that  tells  the 
priority  order  and  an  ordered  set  that  contains  the  integers  in  the  scheduler.  The  crucial 
difference  from  Mob  is  that  the  next  operation  of  a  priority  scheduler  must  return  either 
the  least  or  the  greatest  integer  waiting  to  be  scheduled,  with  the  priority  determined  by 
the  boolean  that  is  fixed  when  the  object  is  created.  The  leastFirst  operation  returns 
the  priority  of  a  PSchd  instance.  If  leastFirst  (q)  is  true,  then  next(q)  will  return  the 
least  element  of  q. 

The  precondition  of  is2waiting  is  “true”  and  the  postcondition  is  “b  =  (2  G  m).” 
Since  many  specifications  have  a  precondition  of  “true”  we  consider  an  omitted  requires 
clause  to  be  syntactic  sugar  for  a  requires  clause  of  the  form  “requires  true.” 
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Figure  4.3:  The  trait  OrderedSet. 


OrderedSet  trait 
imports  Set 
assumes  Ordered 
introduces 

lower  Bound?:  C,  T  ^  Bool 
upper  Bound?:  C,  T  — ♦  Bool 
asserts  for  all  [s:  C,  i,j:  T] 
lowerBound?({},j)  =  true 

lowerBound?(insert(s,j),t)  =  ((i  <  j)  &  lower  Bound?  (s,t)) 
upper  Bound?  =  true 

upperBounU?(insert(5,j),i)  =  ((i  >  j)  &:  upperBound?(5,i)) 


The  free  identifiers  of  a  function  specification’s  precondition  must  be  drawn  from 
the  formed  arguments  of  the  function  specification  (e.g.,  m  in  the  is2waiting  example). 
The  free  identifiers  of  the  postcondition  must  be  drawn  from  both  the  formal  arguments 
of  the  function  specification  and  the  formal  result  identifier  (e.g.,  b  in  the  is2waiting 
example). 

A  term  that  sort-checks  and  only  uses  trait  functions  of  the  signature  SIG{SPEC)  of 
a  type  specification  SPEC  is  a  SPEC-term.  For  example,  the  assertions  in  the  function 
specification  is2vaiting  are  MP-terms.  A  SPEC-term  sort  checks  when  the  number 
and  sorts  of  arguments  to  trait  functions  match  the  signatures  specified  in  the  traits  of 
SPEC.,  and  the  only  equations  are  between  terms  of  the  same  sort.  (An  equation  has 
sort  Bool.)  There  is  no  generic  invocation  that  applies  to  terms,  so  sort-checking  for 
SPEC-texms  is  trivial.  Therefore  we  can  infer  for  each  SPEC-term  a  nominal  sort.  Of 
particular  interest  are  terms  of  nominal  sort  Bool. 

Definition  4.1.1  (5P£'(7-assertion).  A  SPEC -assertion  is  a  SPEC-term  of  nominal 
sort  Bool. 

4.2  Evaluation  of  Assertions 

In  this  section  we  define  the  notion  of  when  an  algebra-environment  pair  models  am 
aissertion  with  respect  to  a  set  of  observations.  This  is  done  by  finding  a  nominal  algebra- 
environment  pair  that  the  given  pair  imitates. 
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Formally,  an  environment  rj  is  nominal  if  and  only  if  it  obeys  the  identity  relation  on 
types  (=).  We  call  an  algebra-environment  pair  nominal  if  the  environment  is  nominal. 

In  Chapter  2  we  have  described  how  to  evaluate  terms  with  free  identifiers  us¬ 
ing  a  nominal  environments,  which  in  that  chapter  were  called  assignments.  If  G 
ENV {X  y  A)  is  a  nominal  environment,  then  ^  is  its  extension  to  a  mapping  from  terms 
to  elements  of  the  carrier  set  of  A.  Recall  that  rj2  works  by  using  the  trait  functions  of 
A  to  evaluate  trait  function  supplications  and  using  itself  to  evaluate  free  identifiers. 

4.2.1  The  Imitates  Relation 

In  this  subsection  we  define  when  one  algebra-environment  pair  imitates  another  with 
respect  to  a  set  of  observations. 

For  soundness  of  reasoning,  we  want  one  algebra-environment  pair  to  imitate  another 
only  if  there  is  no  observation  that  distinguishes  them. 

A  good  notion  of  imitates  for  deterministic  algebras  is  observable  equivalence.  We 
say  that  the  algebra-environment  pair  (C,  »/c)  observably  equivalent  to  {A,t}a) 
respect  to  a  set  of  observations  OBS  if  and  only  if  for  all  observations  P  €  OBS  with 
free  identifiers  from  some  subset  of  X,  P{C,t)c)  =  P{A,t)a)‘ 

However,  observable  equivalence  is  too  strong  for  nondeterministic  algebras.  For 
nondeterministic  algebras  we  want  a  definition  of  “imitates”  that  allows  fewer  possible 
results,  since  in  our  view  a  specification  only  constrains  behavior  and  does  not  completely 
determine  the  exact  set  of  possible  results  of  a  nondeterministic  program.  For  example, 
if  we  specify  ihat  a  procedure  g  returns  an  even  number,  then  an  implementation  of  g 
can  have  as  its  set  of  possible  results  any  nonempty  subset  of  even  numbers. 

Definition  4.2.1  (imitates).  Let  OBS  be  a  set  of  observations,  C  and  A  be  S-algebras, 
and  A  be  a  set  of  typed  identifiers.  Let  qc  ^  ENV{XyC)  and  ^  ENV{X,A)  be 
environments.  Then  the  pair  (C^qc)  imitates  (A^q^)  with  respect  to  OBS  if  and  only  if 
for  all  observations  P  E  OBS  with  free  identifiers  from  some  subset  of  A,  P(C,qc)  Q 
P(A,qA). 


For  example,  consider  MP-algebras  C  and  A  and  environments  qc  G  ENV({x  : 
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Mob},C)  and  tja  6  ENV{{x  :  Mob},  A)  such  that 

Ad[next(x)l(C,*7c)  =  {1,2}  (4.1) 

A4[next(x)l(A,»7^)  =  {1,2, 3, 4}.  (4.2) 

Then  {C,t)c)  imitates  (A,»jyi)  with  respect  to  {next(x)}. 

When  the  set  of  observations  is  fixed,  we  simply  say  that  {C,t}c)  imitates  {A,r)A)- 
In  general,  the  imitates  relation  with  respect  to  a  fixed  set  of  observations  is  not 
synamietric.  However,  we  do  have  the  following  easy  result. 

Lemma  4.2.2.  Let  OBS  be  a  set  of  observations.  Then  the  imitates  relation  with 
respect  to  OBS  is  reflexive  and  transitive.  I 

On  the  other  hand,  for  deterministic  algebras,  the  imitates  relation  is  the  same  as 
observable  equivalence.  For  example,  consider  the  IPT-algebra  A  presented  in  Figure  2.5 
on  page  38.  Let  .Y  =  {x  :  IntPair}.  We  define  two  environments  T/i,r;2  6  BNV{X ,A) 
such  that  T)-i{x)  ^  (1,2,3)  and  ^  (1,2).  We  claim  that  these  environments  are 
observably  equivalent  with  respect  to  the  set  of  observations  described  by  the  following 
set  of  NOAL  programs: 

{first(x),  S0cond(x)}. 

This  claim  is  verified  by  considering  the  following  sets  of  possible  results: 


Af[first(x)l(A,J7i)  =  {1} 

(4.3) 

Af  [second(x)](A,j^i)  =  {2} 

(4.4) 

A([first(x)J(A,72)  =  {1} 

(4.5) 

A4lsecond(x)J(A,^2)  =  {2}. 

(4.6) 

Whenever  one  algebra-environment  pair  does  not  imitate  another  with  respect  to  a 
set  of  observations,  then  there  is  some  observation  in  that  set  that  shows  a  difference. 
However,  if  we  think  of  running  the  program  that  defines  an  observation  in  a  real  imple¬ 
mentation,  we  may  have  to  wait  forever  to  “see”  the  difference,  because  programs  can 
fail  to  halt  and  because  we  do  not  make  assumptions  about  how  the  possible  results  of 
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nondeterministic  operations  are  chosen.  For  exannple,  consider  MP-algebras  C  and  A 
and  environments  rjc  €  ENV{{x  :  Mob},^)  and  €  ENV{{x  :  Mob},  A)  such  that 


A4[next(x)](C',T/cr)  = 

{1,2} 

(4.7) 

Af[next(x)J(A,i?A)  = 

{1}. 

(4.8) 

Then  (C,  t/c)  does  not  imitate  {A,t)a)  with  respect  to  {next(x)},  but  in  a  real  imple¬ 
mentation  there  is  no  guarantee  that  the  result  “2”  will  be  produced  in  tjc  at  any  time. 

The  following  facts  about  the  how  the  imitates  relation  depends  on  sets  of  observations 
will  be  useful  when  comparing  different  programming  languages.  They  are  similar  to  facts 
about  observable  equivalence  studied  by  others  [ST85,  Facts  2-3]. 

Lemma  4.2.3.  Let  OBS  and  OBS'  be  sets  of  observations.  If  OBS  D  OBS'  and  {C,t}c) 
imitates  {A,t}\)  with  respect  to  OBS,  then  {C,r]c)  instates  {A,rij\)  with  respect  to  OBS'. 

■ 

That  is,  the  imitates  relation  with  respect  to  a  larger  set  of  observations  is  a  subset 
of  the  imitates  relation  with  respect  to  smaller  sets  of  observations.  As  an  extreme 
example,  the  imitates  relation  with  respect  to  the  empty  set  of  observations  relates  all 
algebra-environment  pairs.  In  general,  adding  observations  may  allow  one  to  observe 
mere  differences. 

The  following  says  that  the  imitates  relation  with  respect  to  a  set  of  observations 
OBS  is  the  intersection  of  the  imitates  relations  with  respect  to  all  subsets  of  OBS. 

Lemma  4.2.4.  Let  OBS  =  Uig/  OBSi  be  a  set  of  observations.  If  for  each  i  E  I,  (C,  rye) 
imitates  {A,t]a)  with  respect  to  OBSi,  then  (C,  J/c)  imitates  {A,i]a)  with  respect  to  OBS. 

■ 

4.2.2  Models  of  Assertions 

We  now  have  all  the  tools  necessary  to  define  when  an  algebra-environment  pair  models 
an  assertion  with  respect  to  a  set  of  observations. 

Definition  4.2.5  (models).  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  obser¬ 
vations.  Let  P  be  a  SPEC- assertion  whose  set  of  free  identifiers  is  X .  Let  C  be  a  SPEC- 
algebra.  Let  K  be  a  set  of  typed  identifiers  such  that  X  C  Y .  Let  rje  6  ENV{Y,  C)  be  an 
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OBS 

environment.  Then  {C,t}c)  models  P  with  respect  to  OBS,  written  [C,r}c)  H  P,  if  and 
only  if  there  is  some  SP£C-algebra  A  and  some  nominal  environment  tja  €  ENV {Y,  A) 
such  that  {C,Tjc)  imitates  {A,i]a)  with  respect  to  OBS  and  iTTlP]  =  true. 

Notice  that  the  above  definition  works  for  all  environments,  not  just  those  that  obey 
a  subtype  relation. 

VVe  say  that  {C,r]c)  models  P  and  write  {C,7}c)  ^  P  when  {C,r)c)  models  the  SPEC- 
assertion  P  with  respect  to  the  set  of  all  type-safe  NOAL  programs  over  the  nominal 
signature  map  and  presumed  subtype  relation  of  SPEC. 

As  an  example  of  our  definition  of  “models”  consider  the  MP-assertion  “b  =  (2  6  m),” 
where  b  ha^  nominal  type  Bool  and  m  htis  nominal  type  Mob.  Let  B  be  an  MP-algebra. 
Let  ri  6  PAPdb,!!!},  5)  be  such  that  77(b)  =  true  and  ■q{m)  is  the  only  possible  result  of 
A^[ins(make(PSchd,  false),  2)](B,0).  Then  we  have 

(P,77)|=b  =  (2  6m).  (4.9) 

This  follows  because  there  is  some  MP-algebra  A  and  some  nominal  environment  77^  € 
£’iVl/({b,m},  A)  such  that  (B,  77)  imitates  (A,  77^)  with  respect  to  type-safe  NOAL  pro¬ 
grams.  One  type-safe  NOAL  program  is  waiting? (in, 2),  which  can  have  only  one  possi¬ 
ble  result,  since  waiting?  is  specified  to  be  deterministic  (in  both  Mob  and  PSchd).  Since 
A4[waiting?(m,  2)](B,  77)  =  {true},  it  follows  that  A4[waiting?(in,  2)](A,  77^1)  =  {true}] 
therefore  by  the  specification  of  Mob,  ^[(2  G  m)J  =  true.  Similarly,  one  can  show  that 
Va{^)  =  true.  It  follows  that 


77yi[b  =  (2  G  m)l  =  tme.  (4.10) 

4.3  Semantics  of  Polymorphic  Function  Specifications 

Now  that  we  have  a  definition  of  when  an  algebra-environment  pair  models  an  assertion, 
it  is  straightforward  to  define  satisfaction  for  polymorphic  function  specifications.  To 
summarize,  if  the  arguments  model  the  precondition,  then  the  function  must  halt  and 
return  a  result  that  models  the  postcondition.  This  is  a  “total-correctness  approach”  to 
function  specifications. 
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For  concreteness,  in  this  section  we  define  when  a  NOAL  function  satisfies  a  function 
specification  with  respect  to  the  set  of  all  type-safe  NOAL  programs  over  the  referenced 
specification.  The  generalization  to  other  applicative  programming  languages  is  easy; 
one  uses  the  definition  of  “models”  with  respect  to  the  set  of  programs  for  that  language. 
One  can  even  define  satisfaction  with  respect  to  a  subset  of  a  programming  language  by 
using  that  subset  as  the  set  of  observations. 

Although  NOAL  uses  lazy  evaluation,  we  wish  to  avoid  the  complications  of  specifying 
non-strict  functions.  Therefore,  to  define  satisfaction  we  need  only  be  concerned  with 
environments  that  are  proper  in  the  sense  that  no  identifier  denotes  J.. 

Definition  4.3.1  (proper  environment).  An  environment  7/  is  proper  if  and  only  if 
for  every  identifier  x  in  its  domain,  7;(x)  ^  Jl  (i.e.,  •q{x)  is  proper). 

We  now  define  the  semantics  of  NOAL  function  specifications. 

Definition  4.3.2  (satisfies  for  NOAL  functions).  Consider  the  following  function 
specification: 

fun  f(x  :  S)  returns(v  :  T) 
uses  SPEC 
requires  R 
effect  Q. 

Let  the  presumed  subtype  relation  of  SPEC  be  <.  Let  X  =  {xi  :  Si,...,x„  :  S„}. 
A  recursively-defined  NOAL  function  named  f  of  nominal  signature  S  — >  T  satisfies 
the  above  specification  if  and  only  if  for  all  5F£'C-algebras  C,  for  all  environments 
T)c  €  ENV{X ,C]  such  that  rjc  is  proper  and  obeys  <,  the  following  condition  holds.  If 

{C,r,c)\=R,  (4.U) 

then  for  all  possible  results  q  6  M{f(,x)\{C,r}c)i 

9  ^  J- 

<7  €  Cu  U  <  T 
{C,rtc\qh\)  1=  Q- 


(4.12) 

(4.13) 

(4.14) 
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In  the  above  definition,  notice  that  the  possible  results  must  have  some  type  that  is  a 
presumed  subtype  of  the  nominal  result  type.  This  ensures  that  when  a  possible  result  is 
bound  to  an  identifier  of  the  nominal  result  type,  that  binding  obeys  the  presumed  sub- 
type  relation  of  the  referenced  specification.  We  do  not  require  that  the  implementation 
be  type-safe,  although  by  using  a  type-safe  implementation  one  can  ensure  that  the  type 
constraint  is  met  automatically. 

Satisfaction  for  NOAL  programs  is  analogous.  However,  since  a  NOAL  program  does 
not  have  formal  arguments,  we  also  require  that  the  free  identifiers  of  the  program  be 
the  same  as  the  formal  arguments  of  the  specification  it  satisfies. 

As  an  example  of  satisfaction,  the  NOAL  program 

waiting?(m,2), 

where  m  has  nominal  type  Mob,  satisfies  the  specification  is2waiting  given  above.  To  see 
this,  let  C  be  a  MP-algebra,  and  let  t]c  €  ENV{{m  :  Mob},C)  be  an  environment  such 
that  T)c  obeys  the  presumed  subtype  relation  of  MP  and  T/c(n).  We  trivially  have  that 
(C”,  T/c)  \=-  true,  so  the  precondition  is  satisfied.  Let  r  €  A/([waiting?(m,  2)](C,  t;c)  be  a 
possible  result.  Then  r  is  proper,  has  type  Bool  and  is  such  that 

(C^,7c[r/b])hb  =  (2em).  (4.15) 

This  last  equation  follows  from  the  specification  MP,  but  a  formal  proof  requires  the 
techniques  of  Chapter  7. 

4.4  Discussion 

In  this  section  we  discuss  some  limitations  of  our  approach  to  evaluating  assertions, 
the  problems  with  using  our  approach  to  give  a  semantics  to  polymorphic  operation 
specifications,  and  the  plausibility  of  our  semantics. 

4.4.1  Limitations  of  Our  Techniques  for  Evaluating  Assertions 

Our  approach  to  evaluating  assertions  is  similar  to  the  coercer  functions  found  in  Bruce 
and  Wegner’s  work  [BW87].  (See  Chapter  5  for  a  detailed  comparison.)  That  is,  we 
“coerce”  arguments  to  the  nominal  types  of  the  formals  and  then  evaluate  the  assertions. 
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Figure  4.4:  Specification  of  the  function  ins3,  which  inserts  3  in  a  scheduler. 

fun  ins3(m:Mob)  returns(m3:Mob) 
uses  MP 

effect  m3  =  m  U  {3} 

This  coercion  approach  has  limitations,  although  it  works  for  many  examples.  To 
illustrate  the  limitations,  consider  the  function  specification  ins3,  in  Figure  4.4.  An 
obvious  implementation  is  the  following  NOAL  function: 

f\m  ins3(m:Mob) :  Mob  ■  ins(m,3). 

Notice  that  if  we  p<iss  this  implementation  an  object  of  type  PSchd,  we  get  back  an 
object  of  type  PSchd.  However,  neither  the  NOAL  type  system  nor  the  type  system  of 
our  specification  language  can  express  this.  One  way  to  do  so  would  be  to  use  a  kind  of 
bounded  quantification  [CW85].  For  example  we  might  write  something  like: 

fna  ins3(m:t  <  Mob):  t  -  ins(m,3) . 

This  solves  the  problem  with  the  type  of  the  result,  since  we  can  conclude  that  if  ins3 
is  passed  an  instance  of  PSchd,  then  it  returns  an  instance  of  PSchd. 

However,  there  is  another  problem  with  the  coercion  approach  that  is  not  related  to 
types.  Notice  that  if  we  pass  the  denotation  of  new  (PSchd,  true)  to  the  above  imple¬ 
mentation  of  ins3,  we  obtain  an  instance  of  PSchd  whose  abstract  value  is  {true,  {3}). 
However,  from  the  specification  of  ins3,  an  implementation  Ccin  return  an  instance  of 
PSchd  with  abstract  value  {false,  {3}).  So  our  eissertion  language  is  not  strong  enough 
to  state  that  all  other  components  of  an  object  are  unchanged. 

Solving  these  problems  is  a  matter  for  future  work.  One  possible  direction  would  be 
to  adapt  the  work  of  Jategaonkar  and  Mitchell  on  ML  to  specifications  [JM88]. 

4.4.2  Polymorphic  Operation  Specifications 

In  this  section  we  discuss  the  problems  that  arise  in  adapting  our  technique  for  specifying 
polymorphic  functions  to  the  specification  of  polymorphic  operations  in  a  type  specifi¬ 
cation.  (The  type  specification  language  described  in  Chapter  2  can  only  be  used  to 
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specify  types  with  operations  that  are  not  polymorphic.)  Since  we  do  not  have  clear-cut 
solutions  for  these  problems,  we  leave  these  problems  for  future  work. 

The  first  problem  is  that  our  definition  of  when  an  algebra-environment  pair  models 

an  assertion  relies  on  algebras  that  are  known  to  satisfy  a  type  specification,  but  we  use 

satisfaction  for  operation  specifications  in  Chapter  2  to  define  when  an  algebra  satisfies 

a  type  specification.  We  could  perhaps  solve  this  problem  by  changing  our  definition  of 

when  an  algebra-environment  pair  models  an  assertion.  For  example,  let  Q  be  a  SPEC- 

OBS 

assertion.  Suppose  we  say  that  {C,r]c)  )=  Q  if  and  only  if  either  there  is  some  nominal 
(C,  7?'c)  such  that  {C,t]c)  imitates  with  respect  to  OBS  and  t/cIQI  =  true,  or 

there  is  some  algebra  A  that  is  known  to  satisfy  SPEC,  and  some  nominal  T]J^  such  that 
{C,T]c)  imitates  {A,r]j^)  with  respect  to  OBS  and  =  true.  We  could  then  give  an 

inductive  definition  of  when  an  algebra  satisfies  its  specification.  Algebr«is  that  satisfy 
each  operation  specification  without  reference  to  other  algebras  can  be  used  as  a  basis 
for  showing  ttiat  oth#»r  algebras  satisfy  the  type  specification. 

The  second  problem  is  that  we  do  not  want  to  make  the  definition  of  when  an  algebra 
satisfies  a  type  specification  dependent  on  a  set  of  observations,  as  would  be  required  by 
the  above  “solution”  to  the  first  problem.  It  is  not  clear  what  set  of  observations  should 
be  used  to  define  satisfaction  for  operation  specifications.  For  example,  should  programs 
that  use  an  operation  g  be  considered  as  observations  when  defining  satisfaction  for  an 
implementation  of  g?  Furthermore,  it  is  not  standard  practice  to  define  satisfaction  for 
a  type  specification  with  respect  to  a  set  of  observations.  Since  we  do  not  want  the  rest 
of  this  dissertation  to  rest  on  a  nonstandard  definition  of  when  an  algebra  satisfies  a 
specification,  we  leave  these  problems  for  future  work. 

4.4.3  Plausibility  of  Our  Semantics  for  Specifications 

Why  are  the  above  definitions  the  “right”  notions  of  satisfies  and  models? 

One  test  is  that  our  definitions  specialize  to  the  standard  ones  when  the  presumed 
subtype  relation  is  the  identity  relation  on  types  (=).  The  standard  definition  of  when 
a  nominal  algebra-environment  pair  {A,t])  models  an  assertion  Q  is  that  ri\Q\  must  be 
true.  It  is  trivial  that  if  a  5P£’C'- algebra  and  a  nominal  environment  are  such  that  the 
extended  environment  maps  a  SPEC -assertion  to  true,  then  the  algebra  and  environment 
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models  that  assertion,  with  respect  to  all  sets  of  observations.  However,  the  converse  is 
not  true  for  all  sets  of  observations.  As  an  extreme  example,  every  satisfiable  assertion  is 
modeled  by  every  algebra-environment  pair  with  respect  to  the  empty  set  of  observations. 
However,  the  converse  does  hold  if  the  assertion  is  observable  in  the  following  sense. 

To  define  observable  assertions  we  first  define  the  deterministic  observations  that 
characterize  their  behavior  in  nominal  environments. 

Definition  4.4.1  (characteristic  observation).  Let  OBS  be  a  set  of  observations. 
Let  A  be  a  set  of  typed  identifiers.  Let  Qhe  &  SPEC -&ssexi\on  with  free  identifiers  from 
A'.  Then  cg  G  OBS  is  a  characteristic  observation  for  Q  if  and  only  if  eg  is  deterministic, 
the  free  identifiers  of  cg  are  also  from  A,  and  for  all  5P£'C'-algebras  A  and  for  all  nominal 
environments  t]  €  ENV{X ,  A), 

{cQ{A,r,)  =  {b})  ^  mQ]  =  b).  (4.16) 

In  an  environment  that  is  not  proper,  the  right  hand  side  of  the  above  equation  may 
be  X.  When  this  happens  the  characteristic  observation  must  have  X  as  its  only  possible 
result. 

It  only  makes  sense  to  specify  the  behavior  of  a  characteristic  observation  on  nomin2il 
environments,  because  only  nominal  environments  can  be  used  to  evaluate  assertions 
directly.  However,  since  a  characteristic  observation  must  be  a  member  of  OBS,  it  should 
be  thought  of  as  the  denotation  of  a  program  written  using  generic  invocation.  So  we 
think  of  a  characteristic  observation  for  Q  as  telling  us  the  meaning  of  Q,  not  only  for 
nominal  environments  but  for  all  environments. 

Observable  assertions  have  characteiistic  observations  with  respect  to  some  set  of 
observations. 

Definition  4.4.2  (observable  assertion).  Let  OBS  be  a  set  of  observations.  Let  X 
be  a  set  of  typed  identifiers.  A  5F£'(7-assertion  Q  is  observable  with  respect  to  OBS  if 
and  only  if  there  is  some  cg  G  OBS  that  is  a  characteristic  observation  for  Q. 

For  convenience,  we  call  a  5P£'C'-assertion  observable  if  it  is  observable  with  respect 
to  the  set  of  all  type-safe  NOAL  programs  over  the  nominal  signature  map  and  presumed 
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subtype  relation  of  SPEC.  A  characteristic  observation  for  an  observable  assertion  is  thus 
the  denotation  of  a  type-safe  NOAL  program. 

For  example,  consider  the  specification  MP  (Mob  and  PSchd)  and  the  MP-assertion 
“2  €  m”  where  m  has  nominal  type  Mob.  This  assertion  is  observable,  since  the  type-safe 
NOAL  program  waiting?(m,  2)  describes  a  characteristic  observation  for  the  assertion 
“2  e  m.” 

However,  it  is  easy  to  write  assertions  that  are  not  observable.  For  example,  if  one 
specifies  a  type  with  a  trait  function  that  can  give  different  results  for  observably  equiva¬ 
lent  objects,  then  one  can  use  that  trait  function  to  write  assertions  that  are  not  observ¬ 
able.  Furthermore,  if  one  specifies  a  type  whose  carrier  set  can  have  observably  equivalent 
objects  with  different  representations,  then  the  operator  of  our  specification  language 
can  be  used  to  write  assertions  that  are  not  observable. 

Often  one  uses  non-observable  assertions  because  they  may  give  a  more  concise  way 
of  stating  the  observable  properties  of  an  object  than  an  observable  assertion.  However, 
since  we  are  ultimately  interested  in  observable  properties  of  specifications,  we  will  often 
make  the  simplifying  assumption  that  all  assertions  are  observable. 

Our  definition  of  “models”  encompasses  the  standard  one  for  observable  assertions. 
The  following  lemma  states  this  precisely.  It  says  that  a  5P£'C-algebra  and  a  nominal 
environment  model  an  observable  SPEC-&ssertion  with  respect  to  a  set  of  observations 
according  to  our  definition  if  and  only  if  the  pair  models  the  eissertion  according  to  the 
standard  definition. 

Lemma  4.4.3.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let  Q 
be  a  SPEC-asseition  whose  free  identifiers  are  a  set  X. 

Suppose  Q  is  observable  with  respect  to  OBS.  Then  for  all  SPPC- algebras  B  and  for 

OBS  _ 

all  nominal  environments  rjg  £  ENV{X,B),  {B,t]b)  ^  Q  if  and  only  if  i^[Ql  =  true. 

Proof:  Suppose  ^IQ]  =  true.  Then  since  {B,r]B)  imitates  itself  with  respect  to 

OBS 

OBS,  by  definition  {B,t]b)  M  Q- 

OBS 

Conversely  suppose  that  {B,t]b)  f=  Q-  By  definition  there  is  some  SPEC-a.lgebra. 
A  and  some  nominal  environment  tja  €  ENV{X ,  A)  such  that  (B,r]B)  imitates  (y4,r/x) 
with  respect  to  OBS  and  ^\Q\  =  true.  Let  cq  £  OBS  be  a  characteristic  observation 
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for  Q.  Since  {B,t)b)  imitates  (A,  »/>i)  with  respect  to  OBS,  and  the  observation  cq  is 
deterministic,  it  follows  that 


CQ{B,r}B)  =  cq{A,t)a).  (4.17) 

Since  =  true 

cq{A,t)a)  =  {true} 

Therefore  CQ{B,riB)  =  {true},  and  thus 

t}^IQ\  =  true, 

since  cq  is  a  characteristic  observation  for  Q.  I 

We  can  also  use  characteristic  observations  to  test  our  definition  of  “models”  for  non- 
nominal  environments.  The  following  theorem  asserts  that  our  definition  of  “models” 
is  right  in  the  sense  that  whenever  an  algebra-environment  pair  models  an  observable 
assertion  with  respect  to  a  set  of  observations,  then  each  characteristic  observation  for 
that  assertion  has  true  as  its  only  possible  result. 

Theorem  4.4.4.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let 
Q  be  a  5P£'C'-assertion  whose  free  identifiers  are  a  set  X.  Let  5  be  a  algebra  and 

let  r}B  G  ENV{X,B)  be  an  environment. 

OBS 

If  Q  is  observable  with  respect  to  OBS  and  {B,  tjb)  f=  Qi  then  for  each  characteristic 
observation  cg  €  OBS  for  Q,  cq{B,t}b)  =  {frue}. 

OBS 

Proof:  Suppose  that  Q  is  observable  with  respect  to  OBS  and  {B,  tjb)  Q-  By  def¬ 
inition  there  is  some  5f’£'C- algebra  A  and  some  nominal  environment  t)a  €  ENV {X ,  A) 
such  that  {B,rjB)  imitates  {A,t}a)  with  respect  to  OBS  and  =  true.  Let  cg  G  OBS 

be  a  characteristic  observation  for  Q.  Since  {B,  tjb)  imitates  {A,  tia)  with  respect  to  OBS, 
and  eg  is  deterministic,  it  follows  that 

CQ{B,TtB)  =  cq{A,t}a)-  (4.20) 

Since  ^[£J]  =  true  and  eg  is  a  characteristic  observation  for  Q, 


(4.18) 

(4.19) 


n«(.d,i|a)  =  {true]. 


(4.21) 
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Therefore 

cq{B,tib)  =  {true}.  (4.22) 

■ 

The  contrapositive  of  this  theorem  is  important  for  testing.  That  is,  if  an  imple¬ 
mentation  does  not  pass  some  test,  then  we  can  conclude  that  the  implementation  is 
incorrect.  For  example,  consider  a  program  specification  myProg  with  a  trivial  precon¬ 
dition  and  referenced  specification  SPEC.  Suppose  that  the  postcondition  of  myProg 
implies  some  observable  assertion  Q.  (For  example,  the  postcondition  might  be  Q.)  Let 
cq  be  a  characteristic  observation  for  Q,  let  C  be  a  SPEC-algehra.,  and  let  tjc  be  an 
environment  that  obeys  the  presumed  subtype  relation  of  SPEC.  Suppose  that  we  are 
testing  a  NOAL  program  P  and  have  found  a  possible  result  q  6  A4|P|(C,  r/c)  such 
that  cq(C, t;c[9/v])  =  {false},  where  v  is  the  formal  result  of  the  specification.  By  the 
contrapositive  of  the  above  theorem,  P  does  not  satisfy  the  specification  myProg. 

The  converse  of  the  above  theorem  is  also  important  for  testing,  since  we  want  to 
know  when  an  implementation  passes  a  test  case  that  the  implementation  satisfies  the 
specification  on  that  test  case.  Taking  the  above  example  again,  if  for  some  possible  result 
q,  CQ{C,qc[g/'v])  =  {true},  then  we  want  to  know  that  (C',J7c[9/v])  )=  Q.  Although  this 
is  not  true  for  all  environments,  in  the  next  chapter  we  define  subtype  relations  so  that 
it  is  true  whenever  an  environment  obeys  a  subtype  relation. 

Another  test  for  our  definition  of  models  for  assertions  is  whether  one’s  reasoning 

using  the  usual  laws  of  proposition2il  calculus  is  still  valid.  For  example,  the  law  of 

OBS  OBS 

the  excluded  middle  would  say  that  either  {A,r})  [=  Q  or  {A,rj)  ^  -^Q,  but  not 
both.  However,  this  does  not  hold  in  general.  That  is,  if  {A,  q)  does  not  imitate  some 

OBS 

nominal  algebra-environment  pair  with  respect  to  OBS,  then  neither  {A,q)  |=  Q  nor 

OBS 

{A,q)  ^  ->Q.  However,  if  q  obeys  a  subtype  relation  with  respect  to  OBS,  this  cannot 
happen,  as  we  show  in  the  next  chapter. 
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Chapter  5 

Subtype  Relations 


In  this  chapter  we  give  our  formal  definition  of  subtype  relations.  We  also  discuss  issues, 
examples,  and  related  work  on  subtyping. 

To  reason  about  programs  that  exploit  inclusion  polymorphism,  we  rely  on  nominal 
t3rpe  information.  We  write  polymorphic  function  specifications  as  if  each  actual  argu¬ 
ment  were  an  instance  of  the  corresponding  formal  argument’s  nominal  type.  We  also 
verify  programs  by  reasoning  about  expressions  with  nominal  type  T  as  if  each  possible 
result  was  an  instance  of  type  T.  For  example,  to  verify  that  the  NOAL  function 

fun  sumFirst (pl,p2;  IntPair) :  Int  »  add(f irst (pi) .first (p2)) 

implements  the  specification  of  Figure  1.4  we  reason  in  the  body  as  if  pi  and  p2  de¬ 
note  instances  of  IntPair,  even  we  can  pass  instances  of  subtypes  of  IntPair  (such  as 
IntTriple)  as  actual  arguments  to  sumFirst. 

To  guarantee  the  soundness  of  reasoning  based  on  nominal  type  information  we  ensure 
that  each  instance  of  a  subtype  of  some  type  T  imitates  some  instance  of  type  T  and  that 
the  possible  results  of  each  expression  of  some  nominal  type  S  are  instances  of  some 
subtype  of  S.  This  is  the  idea  behind  our  formal  definition  of  subtype  relations.  For 
example,  each  instance  of  type  IntTriple  behaves  like  an  instance  of  IntPair  with  the 
same  first  and  second  components.  By  defining  subtype  relations  so  that  whenever  S  <  T, 
each  instance  of  type  S  cannot  be  observed  to  behave  differently  th2  i  some  instance  of 
type  T,  if  we  verify  some  observable  property  by  reasoning  about  instances  of  type  T, 
then  the  observable  behavior  of  instances  of  type  S  will  not  be  surprising. 

Our  formal  definition  of  subtype  relations  is  parameterized  by  a  set  of  observations 
and  the  semantics  of  a  specification.  We  define  subtype  relations  with  respect  to  arbitrary 
sets  of  observations,  so  that  our  definition  can  be  used  for  many  different  programming 
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languages.  We  define  subtype  relations  using  the  semantics  of  a  specification,  so  that 
we  can  treat  subtype  relations  among  abstract  types.  We  can  deal  with  incompletely 
specified  types,  because  we  take  as  the  semantics  of  a  specification  a  set  of  algebraic 
models.  (That  is,  we  take  a  loose  view  of  specifications.)  So  our  definition  of  subtype 
relations  is  also  independent  of  our  specification  language. 

5.1  Definition  of  Subtype  Relations 

Our  function  specifications  allow  one  to  create  environments  that  obey  a  binary  relation 
on  types.  The  definition  of  subtype  relations  ensures  that  each  such  environment  imitates 
a  nominal  environment. 

Definition  5.1.1  (subtype  relation).  Let  S  be  a  signature  and  let  SPEC  be  a 
nonempty  set  of  S-algebras.  Let  OBS  be  a  set  of  observations.  Let  <  be  a  binary 
relation  on  type  symbols.  Then  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect 
to  OBS  if  and  only  if  for  all  algebras  C  6  SPEC,  there  is  some  A  6  SPEC  such  that 
for  all  sets  of  typed  identifiers  X  and  for  all  environments  t}c  €  ENV{X,  C),  if  tjc  obeys 
<,  then  there  is  some  nominal  environment  tja  €  ENV{X,A),  such  that  {C,t}c)  imitates 
{A,i]a)  with  respect  to  OBS. 

A  trivial  example  of  a  subtype  relation  on  the  types  of  a  specification  with  respect 
to  a  set  of  observations  is  the  empty  relation.  Only  slightly  less  trivi2il  is  the  identity 
relation  on  types;  the  identity  relation  is  always  a  subtype  relation  because  the  imitates 
relation  is  reflexive. 

Consider  the  specification  IPT  presented  in  Figure  2.2.  Let  <  be  the  smallest  reflexive 
relation  on  the  types  of  IPT  such  that  IntTriple  <  IntPair.  Then  <  is  a  subtype 
relation  with  respect  to  the  following  set  of  NOAL  programs,  where  x  :  IntPair; 

{first(x),  second(x)}. 

To  see  this,  let  C  be  an  IPT-algebra,  and  let  tjc  £  ENV (K,  C)  be  an  environment 
that  obeys  <.  Let  t/2  G  ENV(V,C)  be  defined  such  that  if  Tfc(x)  is  a  proper  instance  of 
IntTriple,  then  72(x)  is  an  instance  of  IntPair  such  that  C'#.first(72(x))  =  C',^.fir8t(»7c(x)) 
and  C'^.»econd(»72(x))  =  C'#.s€cond(»7c(x))-  For  all  other  identifiers,  y  €  V,  let  7/2(7)  =  ^c(y)- 
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Then  (C,  rjc)  imitates  (C,  772)  with  respect  to  the  above  set  of  NOAL  programs,  as  is  easily 
checked. 

On  the  other  hand,  a  relation  <  such  that  IntPair  <  IntTriple  is  not  a  subtype 
relation  with  respect  to  the  set  of  type-safe  NOAL  programs  over  the  nominal  signature 
map  of  IPT  and  <.  To  see  this,  consider  the  program 

second(x)  k  (third(x)  k  empty (Int St ream) ) , 

where  x  :  IntTriple.  When  this  program  is  applied  to  an  IPT-algebra  and  a  nominal 
environment  that  maps  x  to  a  proper  value  of  type  IntTriple,  the  only  possible  results 
are  streams  consisting  of  two  integers  (e.g.,  (2,3)  is  the  only  possible  result  when  the 
result  of  madce ( IntTriple,  1 ,2,3)  is  bound  to  x).  However,  if  this  program  is  applied  to 
an  IPT-algebra  and  an  environment  where  the  result  of  make  (IntPair ,  1 ,2)  is  bound  to 
X,  then  the  partial  stream  (2,  ±)  will  result,  since  applying  the  instance  operation  third 
to  an  instance  of  IntPair  results  in  ±.  Therefore,  such  an  algebra-environment  pair 
does  not  imitate  a  nominal  algebra-environment  pair,  and  hence  this  <  is  not  a  subtype 
relation. 

Notice  how  the  set  of  observations  makes  a  difference  in  the  above  example,  because 
with  respect  to  the  set  of  programs 

{first (x) , second(x) } 

where  x  has  type  IntTriple,  IntPair  is  a  subtype  of  IntTriple. 

In  the  rest  of  this  section  we  show  how  our  definition  handles  nondeterministic  and 
incompletely  specified  types. 

5.1,1  Subtypes  can  be  More  Deterministic 

In  this  subsection  we  present  an  example  that  shows  how  a  subtype,  PSchd,  can  be 
more  deterministic  than  its  supertype.  Mob.  Therefore,  by  specifying  a  supertype  with 
nondeterministic  operations,  one  leaves  open  implementation  decisions  that  a  subtype 
can  make. 

The  specification  of  the  type  Mob  is  given  in  Figure  2.6  on  page  39.  The  elements  of 
the  carrier  set  of  Mob  can  be  thought  of  as  finite  sets  of  integers  “waiting”  to  be  scheduled. 


so 


The  ins  operation  produces  a  larger  Mob  object  from  an  existing  one  by  adding  its  integer 
argument  to  the  new  Mob.  The  waiting?  operation  tests  for  membership  in  a  Mob.  The 
empty?  operation  tests  whether  a  Mob  is  empty.  The  next  operation,  when  applied  to  a 
nonempty  Mob,  is  allowed  to  return  any  integer  waiting  in  the  Mob.  Furthermore,  the  result 
of  applying  next  to  an  empty  Mob  is  undefined.  If  B  is  a  maximally  nondeterministic 
Mob- algebra  whose  carrier  set  for  the  type  Mob  consists  of  finite  sets  of  integers,  and  m  is 
a  nonempty  finite  set  of  integers,  then 

^  (5-1) 

=  Bi„t  =  {±,0,l,-1,...}.  (5.2) 


The  scheduler  type  PSchd  is  specified  in  Figure  4.2  on  page  63.  It  is  similar  to  the 
type  Mob,  except  that  its  next  operation  returns  either  the  least  or  the  greatest  integer 
waiting  to  be  scheduled,  with  the  priority  determined  by  the  boolean  that  is  fixed  when 
the  object  is  created.  The  leastFirst  operation  returns  the  priority  of  a  PSchd  instance. 
If  B  is  a  PSchd-algebra  whose  carrier  set  consists  of  pairs  of  booleans  and  sets  of  integers, 
m  is  a  nonempty  finite  set  of  integers,  and  6  is  either  true  or  false,  then  we  have 


D  ^  if  ^ 

nertpschd-int'-'  |  max(m)  otherwise. 


^noxtpschd-Int  (  ^  )  —  Blot. 


(5.3) 

(5.4) 


Let  MP  be  the  specification  that  combines  both  Mob  and  PSchd.  Let  <  be  the  smallest 
reflexive  relation  on  the  types  of  MP  such  that  PSchd  <  Mob.  Let  OBS  be  the  following 
set  of  NOAL  programs,  where  x  :  Mob  and  i  ;  Int 


{waiting?(i,  i),  empty?(x),  next(x)}. 

Let  C  be  an  MP-algebra.  Let  A  be  an  algebra  that  is  the  same  as  C,  except  that  its 
nextMob—int  operation  exhibits  all  the  nondeterminism  allowed  by  its  specification.  Then 
A  is  an  MP-algebra.  Let  t]c  €  ENV{X ,C)  be  an  environment.  Then  we  can  form  an 
environment  tja  6  ENV {X ,  A)  such  that  {C,tjc)  imitates  {A,t]a)  with  respect  to  OBS 
as  follows.  For  each  y  €  A  such  that  y  has  nominal  type  Mob  and  7/c(y)  is  a  proper 
instance  of  PSchd,  we  let  J?..i(y)  be  an  instance  of  Mob  with  the  same  elements;  that  is, 
for  all  j  6  Cint,  C'#e#(?;c(y),i)  is  true  if  and  only  if  A#g;^(7/^(y),  j)  holds.  For  all  other 
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Figure  5.1:  Specification  of  the  deterministic  scheduler  type  Crowd. 

Crowd  in'»mutable  type 

class  ops  [new]  instance  ops  [ins,  waiting?,  next] 

based  on  sort  C  from  Set  with  [Int  for  T] 

op  new(c:CrowdClass)  returns(m:Crowd) 
effect  m  =  {} 

op  ins(c;Crowd,  i:Int)  returns(m:Crowd) 
effect  m  =  c  U  {i} 

op  waiting?(c:Crowd,  i:Int)  returns(b:Bool) 
effect  b  =  i  G  c 

op  empty?fc:Crowd)  returns(b:Bool) 
effect  b  =  (c  =  {}) 

op  next(c:Crowd)  returns(i:Int) 
requires  c  ^  {} 
effect  i  G  c 


identifiers  y'  G  A",  let  77>i(y')  =  rjciy').  (This  makes  sense,  because  the  carrier  sets  of  A 
and  C  are  the  same.)  So  <  is  a  subtype  relation  on  the  types  of  MP  with  respect  to 
OBS. 

5.1.2  Incompletely  Specified  Supertypes 

In  this  subsection  we  show  how  our  definition  of  subtype  relations  handles  incompletely 
specified  tjpes.  This  example  shows  why  our  definition  is  based  on  the  imitates  relation 
between  algebra-environment  pairs.  The  example  also  shows  why  we  chose  the  particular 
order  of  the  quantifiers  in  the  definition  of  subtype  relations. 

The  specification  of  the  type  Mob  is  incomplete,  since  some  algebras  that  satisfy  that 
specification  are  not  observably  equivalent. 

Although  the  type  Mob  has  maximally  nondeterministic  mo  ’  Is  that  in  some  sense 
capture  all  the  behavior  of  the  specification,  there  are  specifications  for  which  no  such 
model  exists.  One  such  type  is  the  deterministic  scheduler  type  Crowd  specified  in  Figure 
5. 1 . 
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Figure  5.2;  Subtype  relationships  among  the  scheduler  types. 


Mob 


Crowd  PSchd 


The  type  Crowd  is  similar  to  the  type  Mob,  except  that  whenever  the  instance  operation 
next  is  defined,  it  is  required  to  be  deterministic.  For  example,  one  Crowd-algebra  is  5™", 
whose  nextcroBd— int  operation  returns  the  minimum  of  its  argument  set. 

Let  MCP  be  the  specification  that  combines  the  specifications  of  Mob,  Crowd,  and 
PSchd.  Let  <  be  the  smallest  reflexive  relation  <  on  the  types  of  MCP  such  that  Crowd  < 
Mob  and  PSchd  <  Mob.  This  relation  is  depicted  in  Figure  5.2. 

To  show  that  the  relation  <  is  a  subtype  relation,  when  we  are  given  an  environment 
that  obeys  <  we  find  a  nominal  environment  that  the  given  environment  imitates  by 
using  a  different  algebra.  For  example,  let  OBS  be  the  following  set  of  NOAL  programs, 
where  x  :  Mob  «ind  i  :  Int 

{waiting?(x,  i),  empty?(x),  next(x)}. 

As  in  the  previous  section,  if  C  is  an  MCP-algebra,  r/c  €  BA'^V(X,C),  t}c  obeys  <,  and 
A  is  an  MCP-algebra  with  the  same  carrier  sets  and  trait  functions  cis  C  but  with  a 
nextMob_int  operation  that  is  as  nondeterministic  as  its  specification  allows,  then  we  can 
form  an  environment  t]a  €  ENV{X ,A)  such  that  {C,i]c)  imitates  {A,t]a)  with  respect 
to  OBS.  So  <  is  a  subtype  relation  on  the  types  of  MCP  with  respect  to  OBS.  We 
must  be  able  to  pick  a  different  an  algebra  other  than  C,  because  the  operations  of  C 
may  not  be  nondeterministic  enough  for  us  to  find  a  nominal  environment  that  a  given 
environment  that  obeys  <  imitates.  Our  definition  of  subtype  relations  forces  us  to  pick 
a  single  algebra  A  for  each  C,  so  that  we  can  reason  about  an  entire  program  using  the 
same  algebra  A  as  a  model,  without  changing  algebras  for  each  expression. 
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Let  us  consider  why  we  do  not  want  a  relation  on  types  such  that  PSchd  <  Crowd 
to  be  a  subtype  relation  with  respect  to  type-safe  NOAL  programs  over  the  nominal 
signature  map  of  MCP  and  <.  Let  rj  be  an  environment  defined  so  that  the  result  of 
new  (PSchd,  true)  is  bound  to  xl  and  the  result  of  new(PSchd, false)  is  bound  to  x2, 
where  xl  and  x2  are  both  of  nominal  type  Crowd.  Consider  the  follovdng  program: 

fun  bool2int(b:  Bool):  Int  =  if  b  then  1  else  0  fi; 
bool2int (empty? (xl) )  k  (bool2int (empty? (x2)) 

*  (next(ins(ins(xl,l) ,2))  ft  (next(ins(ins(x2,l) ,2)) 
ft  empty(IntStream)))). 

In  the  environment  rj,  the  only  possible  result  of  this  program  is  the  stream  (1, 1, 1, 2).  In  a 
nominal  environment,  however,  the  objects  bound  to  xl  and  x2  must  be  instances  of  type 
Crowd.  Clearly,  the  denotations  of  xl  and  x2  in  a  nominal  environment  must  be  empty 
Crowds  if  the  result  of  the  above  program  is  to  be  (1,1, 1,2).  Using  the  specification 
of  the  trait  Set  [GH86a,  Page  146],  whose  proper  elements  are  generated  by  the  trait 
functions  {}  and  “insert”  and  are  partitioned  by  the  trait  function  €,  we  can  conclude 
that  if  the  denotations  of  xl  and  x2  are  empty  instances  of  Crowd,  then  they  must  be  the 
same  object  and  therefore  that  ins(ins(xl ,  1)  ,2)  and  ins(ins(x2, 1)  ,2)  must  denote 
the  same  object.  Therefore,  since  the  next  operation  of  Crowd  is  deterministic,  the  last 
two  elements  of  the  stream  must  be  either  both  1  or  both  2.  So  presuming  that  PSchd  is 
a  subtype  of  Crowd  would  lead  to  surprising  results.  Another  way  to  look  at  this  is  that 
the  behavior  of  these  two  PSchd  objects  is  surprising  when  they  are  thought  of  as  Crowd 
objects. 

Our  definition  prevents  a  relation  on  types  such  that  PSchd  <  Crowd  from  being  a 
subtype  relation,  because  we  use  imitates  for  algebra-environment  pairs.  This  allows  us 
to  observe  more  than  one  object  at  a  time.  Although  each  individual  instance  of  PSchd 
“acts  like”  some  instance  of  Crowd,  in  general  these  instances  of  Crowd  must  be  from 
different  algebras.  For  example,  the  PSchd  object  created  by  new  (PSchd,  true)  acts  like 
the  Crowd  object  created  by  new(Crowd)  in  B'™",  since  it  has  the  same  responses  to 
type-safe  N0.4L  programs  that  observe  it  through  an  identifier  of  nominal  type  Crowd. 
Similarly,  the  PSchd  object  created  by  new(PSchd, false)  acts  like  the  Crowd  object 
created  by  new  (Crowd)  in  As  we  saw  above,  we  cannot  treat  both  empty  PSchd 
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objects  as  if  they  were  instances  of  type  Crowd,  because  taken  together  they  do  not 
act  like  Crowd  objects.  Therefore,  a  correct  characterization  of  subtype  relations  using 
relationships  among  objects,  such  as  the  one  given  in  the  next  chapter,  requires  some 
“bundling”  of  the  object  relationships  to  properly  distinguish  between  PSchd  and  Crowd. 

5.2  Reasoning  about  Environments  that  obey  a  Subtype  Re¬ 
lation 

Because  our  method  for  evaluating  assertions  (see  Chapter  4)  relies  on  the  imitates 
relation  and  nominal  environments,  there  are  several  ways  in  which  standard  reaisoning 
could  fail.  For  example,  our  method  of  evaluating  assertions  might  be  ambiguous,  proof 
by  contradiction  might  be  invalid,  and  we  might  not  be  able  to  conclude  that  if  P  and 
P  =>  Q  hold,  then  Q  holds.  In  this  section  we  show  that  none  of  these  possibilities  can 
happen  if  we  limit  ourselves  to  re«LSoning  about  observable  assertions  and  environments 
that  obey  a  subtype  relation  with  respect  to  sufficiently  large  set  of  observations.  The 
results  of  this  section  ''omplete  the  plausibility  arguments  of  the  last  chapter  and  are 
used  in  proving  the  soundness  of  our  verification  techniques. 

A  fundamental  pitfall  in  our  definition  of  models  for  assertions  is  that  it  might  be 
possible  for  an  assertion  to  be  both  true  and  false,  or  neither  true  nor  false.  In  the 
following  lemma  we  show  that  observable  assertions  cannot  be  both  true  and  false. 

Lemma  5.2.1.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let  Q 
be  a  SPEC -assertion  whose  set  of  free  identifiers  is  X.  Let  B  be  a  SPEC-algehra  and 
let  T)g  6  ENV{X ,B)  be  an  environment. 

Suppose  that  cq  €  OBS  is  a  characteristic  observation  for  Q  and  c-,g  6  OBS  is  a 
characteristic  observation  for  ->Q.  If  models  Q  with  respect  to  OBS  then  {B,t}b) 

does  not  model  -->Q  with  respect  to  OBS,  and  furthermore  if  {B^rjg)  models  -'Q  with 
respect  to  OBS  then  {B,r)B)  does  not  model  Q  with  respect  to  OBS. 

OBS  OBS 

Proof:  Suppose  for  the  sake  of  contradiction  that  {B^r^g)  H  Q  and  {B^r/g)  |= 
-'Q.  By  definition,  there  is  some  SPEC-aigehra  A  and  some  nominal  environment  € 
EXV{X ,  A)  such  that  {B,t]b)  imitates  {A,t}/^)  with  respect  to  OBS  and 


VaIQ]  =  true. 


(5.5) 
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By  Theorem  4.4.4, 


Since  c-,Q  6  OBS, 


cq{B,i]b)  =  {true) 
c-^{B,t}b)  =  {true). 

c.^q{A,jja)  =  {ti'ue). 


Since  rjA  is  nominal,  by  definition  of  characteristic  observation 


(5.6) 

(5.7) 


(5.8) 


(5.9) 

But  this  is  a  contradiction  to  the  definition  of  evaluation  in  nominal  environments.  I 
The  above  lemma  rules  out  an  observable  assertion  being  both  true  and  false,  but  it 
does  not  guarantee  that  an  assertion  is  either  true  or  false.  For  example,  if  an  environment 
does  not  imitate  a  nominal  environment,  then  an  assertion  may  be  neither  true  nor  false 
in  that  environment.  However,  by  restricting  our  attention  to  proper  environments  that 
obey  a  subtype  relation  and  sets  of  observations  that  can  test  whether  an  environment 
is  proper,  we  can  show  that  the  law  of  the  excluded  middle  holds,  as  in  the  following 
theorem. 


Theorem  5.2.2.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let  < 

be  a  binary  relation  on  the  types  of  SPEC.  Let  be  a  5P£’C-assertion  whose  set  of  free 

identifiers  is  X .  Let  B  be  a  5FBC'- algebra  and  let  tjb  6  ENV{X  ^B)  be  an  environment. 

Suppose  that  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  OB5, 

TfB  is  proper,  riB  obeys  <,  cg  €  OBS  is  a  characteristic  observation  for  (J,  c-,g  €  OBS 

is  a  characteristic  observation  for  ->Q,  and  for  all  5PBC-algebras  A  and  for  all  nominal 

environments  tja  6  ENV{X ,  A),  if  {B,t)b)  imitates  {A,t)a)  with  respect  to  OBS,  then 

OBS  OBS 

T/yi  is  proper.  Then  either  (B,7/b)  Q  {PiIb)  -"Q,  but  not  both. 

Proof:  Since  rjB  obeys  <  and  <  is  a  subtype  relation,  there  is  some  5PPC'-algebra  A 
and  some  nominal  environment  tia  G  ENV {X ,  A)  such  that  {B,i]b)  imitates  (^4,7/^)  with 
respect  to  OBS.  By  hypothesis  tja  is  proper.  So  either  ^|Q]  =  true  or  ^\Q\  =  fahe. 
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OBS  OBS 

So  by  definition,  either  (B,t}b)  \=  Q  or  (B,t}b)  ~>Q-  By  the  previous  lemma  it 

cannot  be  both.  I 

So  for  environments  that  are  proper  and  obey  a  subtype  relation,  we  can  think  of  our 
definition  of  models  for  assertions  as  assigning  a  single  truth  value  to  each  observable 
assertion. 

We  also  want  to  show  that  we  can  reason  about  environments  that  obey  a  subtype 
relation  using  the  other  propositional  connectives.  To  prove  the  validity  of  the  usual  laws 
that  govern  the  other  propositional  connectives,  we  first  need  to  tie  the  truth  value  of  an 
assertion  in  an  environment  to  all  the  nominal  environments  it  imitates.  This  is  done  by 
the  following  two  lemmas. 

The  following  lemma  is  a  direct  consequence  of  our  technique  for  evaluating  assertions 
and  the  transitivity  of  the  imitates  relation.  It  says  that  an  algebra-environment  pair 
models  each  assertion  modeled  by  an  algebra-environment  pair  that  it  imitates. 

Lemma  5.2.3.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let  P 
be  a  5P£'C-assertion  with  free  identifiers  from  A'.  Let  C  and  A  be  SPEC-&\gehid&.  Let  Y 
be  a  set  of  typed  identifiers  such  that  X  QY.  Let  rfc  €  ENV  (T,  C)  and  tja  €  ENV  (T,  A) 
be  environments. 

OBS  OBS 

If  (C,  T]c)  imitates  (A,  tja)  with  respect  to  OBS  and  (A,  tja)  \=  P,  then  (C,  ijc)  [=  P. 

■ 


We  also  need  something  like  a  converse  to  the  above  lemma.  The  following  lemma  is 
nearly  the  converse  to  the  above,  but  the  hypothesis  is  stronger,  since  the  assertion  must 
be  observable  and  the  imitated  environment  must  be  nominal. 


Lemma  5.2.4.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let  R 
be  a  5P£'C-assertion  whose  set  of  free  identifiers  is  X.  Let  C  and  A  be  5P£'C-algebras. 
Let  r]c  €  ENV{X,C)  and  tja  €  ENV{X,A)  be  environments. 

If  R  is  observable  with  respect  to  OBS,  tja  nominal,  {C,t}c)  imitates  {A,r)A)  with 

OBS  OBS 

respect  to  OBS,  and  (C, t/c)  f=  R,  then  (>l, ^/i)  \=  R. 


Proof:  Suppose  that  R  is  observable  with  respect  to  OBS,  t]a  is  nominal,  (C,Tfc) 

OBS 

imitates  (A,t}a)  with  respect  to  OBS,  and  (C,  7c)  f=  R-  Since  R  is  observable  with 
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respect  to  OBS,  there  is  some  characteristic  observation  cr  €  OBS  for  R.  By  Theo¬ 
rem  4.4.4,  cr{C,t]c)  =  {<r«e}.  Since  {C,J)c)  imitates  {A,rfA)  with  respect  to  OBS,  and 
since  cr  is  deterministic, 

CR(C,r}c)  =  cr(A,t}a).  (5.10) 

OBS 

Since  Cr  is  a  characteristic  observation  and  tja  is  nominal,  {A,t)a)  i2.  i 

The  following  theorem  says  that  the  usual  way  one  reasons  about  implication  is  valid 
for  environments  that  obey  a  subtype  relation. 

Theorem  5.2.5.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let 
P  and  Q  be  5PFC-assertions.  Let  A"  be  a  set  of  typed  identifiers  that  contains  the 
free  identifiers  of  P  and  Q.  Let  C  be  a  SP^^C-algebra  and  let  r)c  E  ENV{X  ,C)  be  an 
environment. 

Suppose  that  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  OBS, 
that  ~>P,  Q,  and  P  Q  are  observable  with  respect  to  OBS,  and  that  rjc  obeys  <. 

OBS  OBS  OBS 

Then  (C,r]c)  |=  P  ^  if  and  only  if  either  (C,  77^7)  )=  ->P  ox  {C,r)c)  h  Q- 

Proof:  Since  <  is  a  subtype  relation  and  7c  obeys  <,  there  is  some  SPEC-algebra 
A  and  some  nominal  environment  tia  €  ENV{X,A)  such  that  {C,‘qc)  imitates  {A,rjA) 
with  respect  to  OBS. 

OBS 

Suppose  that  {C,t)c)  f=  P  Q.  Since  P  Q  is  observable  with  respect  to  OBS 
and  TfA  is  nominal,  by  Lemma  5.2.4, 

OBS 

{^,Va)  1=  P=>Q.  (5.11) 

So  by  Lemma  4.4.3, 

^[P  =►  Q\  =  true.  (5.12) 

So  by  the  definition  of  evaluation  in  nominal  environments,  either  ^[-'P]  =  true  or 
_  OBS  OBS 

VA  IQ]  =  true.  So  by  definition,  either  ((7,70)  t=  “'Por(C,  7c)  H  Q- 

OBS 

Suppose  that  {C,  iic)  |=  ~'P-  Since  -iP  is  observable  with  respect  to  OBS  and  t)a  is 
nominal,  by  Lemma  5.2.4, 

OBS 

(A, tia)  N  -.P- 


(5.13) 
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So  by  Lemma  4.4.3, 


=  true.  (5-14) 

So  by  the  definition  of  evaluation  in  nominal  environments,  <5]  =  true.,  and 

OBS 

hence  (C, 77c)  f=  P  Q  by  definition. 

OBS  OBS 

Similarly,  if  (C,  77c)  [=  Q,  then  (C,  77c)  P=^Q.t 

Since  the  set  {“',=>■}  is  a  complete  set  of  propositional  connectives,  our  usual  rea¬ 
soning  about  observable  assertions  is  valid  in  proper  environments  that  obey  a  subtype 
relation  with  respect  to  a  sufficiently  large  set  of  observations.  For  example,  standard 
reasoning  about  observable  assertions  in  environments  that  obeys  a  subtype  relation  with 
respect  to  the  set  of  type-safe  NOAL  programs  is  valid,  because  the  NOAL  programs  of 
the  form  isDef?(x)  ensure  that  a  proper  environment  can  only  imitate  another  proper 
environment. 

Another  strange  aspect  of  our  definition  of  models  is  the  way  the  truth  of  an  assertion 
in  a  given  environment  seems  to  depend  on  all  the  bindings  in  that  environment.  This 
is  because  the  imitates  relation  depends  on  all  the  bindings  in  an  environment  and  not 
just  those  used  in  some  a.ssertion.  We  show  in  the  following  lemma  that  if  we  shrink 
the  domain  of  an  environment  to  excise  some  identifiers  that  do  not  occur  free  in  am 
assertion,  then  the  truth  value  of  that  assertion  in  the  environment  is  unchainged. 


Lemma  5.2.6.  Let  OBS  be  a  set  of  observations.  Let  SPEC  be  a  specification.  Let  C 

be  a  5P£'C'-algebra.  Let  Q  be  a  5P£'C-assertion  whose  set  of  free  identifiers  is  X.  Let 

r}c  €  ENV{X ,C)  be  an  environment.  Let  q  €  Ctypes  be  a  tuple  of  objects  from  the 

carrier  set  of  C,  and  let  z  be  a  tuple  of  typed  identifiers,  none  of  which  is  in  X. 

OBS  OBS 

If  (C,77c[g/z])  h  Q,  then  (C,  77)  \=  Q. 

OBS 

Proof:  Suppose  that  (C,  qcl?/^)  h  Q-  By  definition  there  is  some  5P£'C'-algebra  A 
and  some  nominal  environment  774[r/z]  such  that  (C, 77c[7/z])  imitates  (A, 77yi[r/z])  with 
respect  to  OBS  and  77/i[r/z][(51  =  true.  Since  the  Zj  do  not  occur  free  in  Q,  ffA\Q\  =  true. 
Furthermore,  {C,r]c)  imitates  (A, 774)  with  respect  to  OBS.  So  by  definition  {C,r]c)  H  Q- 


If  we  extend  an  environment  by  adding  some  binding,  we  may  not  be  able  to  conclude 
that  an  assertion  that  held  in  the  original  environment  still  holds,  because  the  extended 


environment  may  not  imitate  a  nominal  environment.  But  if  the  extended  environment 
obeys  a  subtype  relation  and  the  assertion  is  observable,  then  the  truth  value  of  the 
assertion  is  unchanged,  as  we  show  in  the  following  lemma. 

Lemma  5.2.7.  Let  OBS  be  a  set  of  observations.  Let  SPEC  be  a  specification.  Let  C 
be  a  S PEC -aigehr a..  Let  P  be  a  5PPC'-assertion  whose  set  of  free  identifiers  is  X.  Let 

<  be  a  binary  relation  on  the  types  of  SPEC.  Let  ■qx  G  ENV{X ,  C)  be  an  environment. 

Let  Y  be  a  set  of  typed  identifiers  such  that  X  C  Y.  Let  qy  G  ENV(Y,C)  be  an 

environment  such  that  for  all  x  G  A',  qvi^^)  =  Vxi'x.). 

OBS 

If  {C,qx)  1=  P,  f}Y  obeys  <,  <  is  a  subtype  relation  on  the  types  of  SPEC  with 

OBS 

respect  to  OBS,  and  P  is  observable  with  respect  to  OBS,  then  {C,qY)  P- 

OBS 

Proof:  Suppose  that  {C,qx)  H  Vy  obeys  <,  <  is  a  subtype  relation  on  the 
types  of  SPEC  with  respect  to  OBS,  and  P  is  observable  with  respect  to  OBS.  Since 

<  is  a  subtype  relation,  there  is  some  SPEC-a\ge\>xa.  A  and  some  nominal  environment 
q'y  €  ENV{Y,A)  such  that  {C,qy)  imitates  {A,qy)  with  respect  to  OBS.  Let  q'x  Vy 
restricted  to  A'’.  Then  {C,qx)  imitates  {A,q’x)  with  respect  to  OBS.  Since  the  set  of 
free  identifiers  of  P  is  A', 

=  ^\P\  (5-15) 

OBS  OBS 

Since  P  is  observable,  {C,qx)  H  P,  and  {A,qx)  is  nominal,  by  Lemma  5.2.A  {A,  q'x)  H 

_  _  OBS 

P.  So  by  Lemma  4.4.3,  =  true.  So  q'ylP]  =  true  and  thus  {A,qy)  [=  P.  Since 

OBS 

q'y  is  nominal,  by  Lemma  5.2.3  {C,qy)  ^  P.  ■ 

5.3  Discussion 

In  this  section  we  first  discuss  several  aspects  of  subtype  relations.  We  show  how  subtyp¬ 
ing  varies  with  observations.  We  discuss  the  meaning  of  tests  on  environments  that  obey 
a  subtype  relation  and  a  strategy  for  testing  functions  that  exploit  inclusion  polymor¬ 
phism.  Finally  we  discuss  the  degrees  of  freedom  one  has  when  designing  a  collection  of 
types  to  ensure  certain  subtype  relationships.  We  have  discussed  nondeterministic  and 
incomplete  specifications  above.  Continuing  this  discussion,  in  the  final  subsections  of 
this  section  we  discuss  how  the  preconditions  of  operations  (requirements),  exceptions, 
and  virtual  types  affect  subtype  relations. 
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5.3.1  How  Subtyping  Varies  with  Observations 

Like  the  imitates  relation,  whether  a  binary  relation  on  types  is  a  subtype  relation  varies 
with  the  observations  one  makes.  As  a  trivial  example,  every  binary  relation  on  types 
is  a  subtype  relation  with  respect  to  the  empty  set  of  observations.  If  a  feature  is 
added  to  one’s  programming  language,  then  some  binary  relations  on  types  may  cease 
to  be  subtype  relationships  with  respect  to  programs  written  in  the  new  programming 
language.  However,  if  we  remove  a  feature  from  a  language,  by  the  following  lemma,  old 
subtype  relations  are  still  subtype  relations  with  respect  to  the  smaller  language. 

Lemma  5.3.1.  Let  SPEC  be  a  set  of  E-algebras.  Let  OBS  and  OBS'  be  sets  of  obser¬ 
vations. 

If  OBS  2  OBS\  then  all  subtype  relations  on  the  types  of  SPEC  with  respect  to 
OBS  are  also  subtype  relations  with  respect  to  OBS'.  I 

One  way  to  handle  an  enlarged  programming  language  is  suggested  by  the  following 
lemma.  If  one  knows  that  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect 
to  OBSi,  then  to  verify  that  <  is  a  subtype  relation  with  respect  to  OBSi  U  OBS2  one 
merely  has  to  verify  that  <  is  a  subtype  relation  with  respect  to  OBS2. 

Lemma  5.3.2.  Let  SPEC  be  a  set  of  E-algebras.  Let  OBS  =  OBSi  be  a  set  of 
observations. 

If  for  each  z  G  /,  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  OBSi, 
then  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  OBS.  I 

We  will  have  more  to  say  about  how  certain  features  of  programming  languages  affect 
subtype  relations  in  Chapter  9. 

5.3.2  Testing  Functions  that  use  Subtypes 

In  this  subsection  we  show  that  the  results  of  test  cases  have  the  usual  meaning  for  func¬ 
tions  that  use  inclusion  polymorphism  and  we  offer  a  strategy  for  testing  such  functions. 
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At  the  end  of  Chapter  4  we  showed  that  if  an  implementation  does  not  pass  a  test 
case,  then  the  implementation  is  incorrect.  We  will  now  show  that  the  converse  holds: 
if  an  implementation  passes  a  test  case  we  can  then  conclude  that  the  implementation 
satisfied  its  specification  for  that  test  case.  For  example,  suppose  we  make  the  following 
call  to  an  implementation  of  sumFirst 

sumfirstCmakedntPair,  1,2) ,  make(lRtTriple,4,5,6)) 

and  the  implementation  returns  5.  This  is  what  we  expect  from  the  specification  given 
in  Figure  1.4,  because  the  only  possible  results  of 

first (make(IntPair , 1 ,2)) 


and 


first (make (IntTr iple ,4 , 5,6)) 

are  1  and  4  (respectively).  We  want  to  conclude  that  the  implementation  satisfies  its 
specification  for  this  test  case.  This  conclusion  is  valid  because  we  can  observe  that  the 
result  of  our  test  is  5  and  that  the  first  components  of  the  two  arguments  are  1  and  4 
(respectively). 

We  can  model  a  test  case  as  the  characteristic  observation  for  a  function  specification’s 
postcondition.  The  following  lemma  says  that  in  an  environment  that  obeys  a  subtype 
relation,  whenever  a  characteristic  observation  for  the  postcondition  returns  true,  the 
implementation  satisfies  its  specification  on  that  test  case. 

Lemma  5.3.3.  Let  SPEC  be  a  specification.  Let  OBS  be  a  set  of  observations.  Let  Q 
be  a  SPEC -assertion,  whose  set  of  free  identifiers  is  X.  Let  be  a  SPEC-algebra  and 
let  t]b  6  ENV{X ,  B)  be  an  environment. 

If  cq  €  OBS  is  a  characteristic  observation  for  ^,  <  is  a  subtype  relation  on  the  types 

OBS 

of  SPEC  with  respect  to  OBS,  tjb  obeys  <,  and  CQ{B,rjB)  =  {true},  then  {B,t]b)  f=  Q. 

Proof:  Suppose  that  cq  E  OBS  is  a  characteristic  observation  for  Q,  <  is  a  subtype 
relation  on  the  types  of  SPEC  with  respect  to  OBS,  tjb  obeys  <,  and  cq{B,  tjb)  =  {I me). 
Since  <  is  a  subtype  relation  with  respect  to  OBS,  there  is  some  SPEC-algebra  A  and 
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some  nominal  environment  tja  €  ENV{X,A)  such  that  (B,t}b)  imitates  {A,t]a)  with 
respect  to  OBS.  Since  cq  G  OBS, 

cqiB^TjB]  =  {true}  =  cq{A,t]a).  (5.16) 

Since  by  definition  Q  is  observable  and  since  rfA  is  nominal,  by  Lemma  5.2.4  we  have 

OBS 

{A,riA)  f=  Q-  Since  {B,i]b)  imitates  (A,t)a)  with  respect  to  OBS,  by  Lemma  5.2.3, 

OBS 

{B,nB)  h  Q-  ■ 

One  implication  of  the  above  lemma  is  that  we  can  use  instances  of  subtypes  for  test 
data  and  interpret  the  results  of  such  tests  normally.  This  raises  the  question  of  whether 
one  should  use  instances  of  subtypes  for  test  data.  The  question  of  what  test  data  to 
use  is  important,  because  during  testing  one  is  always  faced  with  limited  resources  (e.g., 
time  and  computers)  and  so  one  must  make  trade-offs  among  test  cases. 

A  useful  test  strategy  for  testing  functions  that  use  inclusion  polymorphism  is  to 
concentrate  on  nominal  test  data  instead  of  using  instances  of  subtypes  for  test  data. 
The  reason  is  that  if  it  can  be  shown  by  some  test  that  a  function  does  not  meet  its 
specification,  then  this  problem  can  be  uncovered  by  a  test  that  uses  arguments  that  are 
instances  of  the  function’s  nominal  argument  types.  Furthermore,  since  a  subtype  might 
only  exhibit  some  but  not  all  of  the  behavior  of  its  supertypes,  testing  with  instances 
of  a  subtype  might  fail  to  uncover  certain  bugs.  For  the  same  reason,  when  testing  a 
function  it  is  wise  to  use  an  implementation  of  each  type  that  is  as  nondeterministic  as 
the  specification  of  that  type  allows. 

5.3.3  Subtypes  can  have  Weaker  Requirements 

Our  definition  of  subtype  relations  also  allows  a  subtype  to  be  more  defined  than  its 
supertypes,  in  the  sense  that  the  subtype’s  requires  clause  may  be  weaker.  For  example, 
consider  the  type  PSchd2,  where  PSchd2  is  exactly  like  PSchd  except  that  the  next 
operation  is  specified  as  in  Figure  5.3.  This  specification  says  that  when  the  argument 
to  next  is  empty,  the  only  possible  result  is  0.  Let  P2  be  the  specification  that  combines 
PSchd  and  PSchd2.  Then  the  smallest  reflexive  relation  <  on  the  types  of  P2  such  that 
PSchd2  <  PSchd  is  a  subtype  relation  with  respect  to  the  following  set  of  NOAL  programs: 

{next(x),  waiting?(x,  i),  leastFirst(x)} 
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Figure  5.3:  Specification  of  the  type  PSchd2,  which  is  more  defined  than  PSchd. 
PSchd2  immutable  type 

class  ops  [new]  instance  ops  [ins,  waiting?,  next,  leastFirst] 
based  on  sort  C  from  Pair 

with  [Bool  for  Tl,  OrderedSet  with  [Int  for  T]  for  T2] 

%  new,  ins,  waiting?,  empty?,  leastFirst  as  in  Figure  4.2. 

op  next(p:PSchd2)  returns(i:Int) 
effect  ((p.second  =  {})  i=0) 

&  ((p.second  ^  {})  ^  i  ^  p.second) 

&  (p.first  =>  lowerBound?(p.second,i)) 

Sz  ((-ip. first)  =>  upperBound?(p. second, i)) 


where  x  ;  PSchd  and  i  :  Int.  This  follows  because  if  C  is  a  P2-algebra  and  tj  is  an  environ¬ 
ment  such  that  7;(x)  denotes  an  empty  instance  of  PS chd2,  then  Af  [next(x)](>l, »;)  =  {0}. 
But  if  A  is  a  maximally  nondeterministic  P2-algebra  and  denotes  an  empty  instance 
of  PSchd,  then  A<Inext(x)I(A, r;)  =  {J.,0, 1  -  1,...}. 

Allowing  a  subtype  to  be  more  defined  seems  right,  since  the  idea  of  a  requires  clause 
is  to  leave  the  behavior  of  an  operation  undefined  when  the  precondition  is  not  met. 


5.3.4  Exceptions  and  Subtyping 

Instead  of  specifying  operations  with  nontrivial  preconditions  or  arbitrarily  defining  a 
result,  as  was  done  for  PSchd2,  another  way  of  dealing  with  boundary  conditions  is  to 
specify  that  an  operation  should  signal  an  exception. 
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In  this  subsection,  we  again  consider  operation  specifications  to  be  syntactic  sugar 
for  operation  specifications  that  return  instances  of  a  OneOf  type  (see  Chapter  2).  For 
example,  when  the  specification  of  the  type  Mob2  given  in  Figure  2.8  on  page  41  says  that 
the  next  operation  signals  “empty(nil)”  when  it  is  passed  an  empty  instance  of  Mob2,  we 
mean  that  it  returns  the  result  of 

make-empty (OneOf [normal : Int ,  empty : Null] ,  nil (Null)) 

when  it  is  passed  an  empty  instance  of  Mob2.  Consider  the  specification  MM2  that 
incorporates  both  our  original  Mob  type  and  the  type  Mob2.  Let  <  be  a  relation  on  type 
symbols  such  that  Mob2  <  Mob.  Then  <  is  not  a  subtype  relation  on  the  types  of  MM2 
with  respect  to  type-safe  NOAL  over  the  nominal  signature  map  of  MM2  and  <.  This 
is  because  exceptions  are  distinct  from  normal  results.  For  example,  let  x  have  nominal 
type  Mob.  In  an  environment  where  x  is  bound  to  the  result  of  new(Mob2),  the  only 
possible  result  of  the  program 

value [Bool] (empty? (x) .normal) 

&  (hasTag?(next(x) .normal)  ft  empty (BoolSt ream) ) 

is  the  stream  {true,  false),  since  the  result  of  next(x)  is  a  OneOf  with  the  tag  empty 
in  this  environment.  This  is  not  possible  in  a  nominal  environment,  since  the  result  of 
next  (x)  can  only  have  tag  normal.  So  although  we  said  that  the  result  of  next  when 
applied  to  an  empty  instance  of  Mob  is  “undefined,”  there  are  certain  things  that  an 
implementation  of  Mob  cannot  do,  such  as  signalling  an  exception.  The  type  declarations 
in  a  specification  are  enforced  even  if  a  requires  clause  is  not  satisfied^.  Therefore, 
for  each  instance  operation,  a  subtype  cannot  have  more  exceptional  results  than  its 
supertypes. 

The  program  exhibited  in  the  above  example  also  shows  that  Mob  is  not  a  subtype 
of  Mob2.  However,  a  subtype  can  have  fewer  exceptional  results  than  its  supertype  if 
the  supertype’s  specification  allows  a  nondeterministic  choice  between  signalling  and 
returning  normal  results.  For  example,  consider  the  type  Mob3  as  specified  in  Figure  5.4. 
The  next  operation  of  Mob3  hcis  a  requires  clause,  like  Mob,  but  its  signature  allows  the 

’These  type  declarations  are  enforced  because  our  definition  of  algebras  and  their  operations  precludes 
type  violations. 
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Figure  5.4:  Specification  of  the  scheduler  type  Mob3. 

Mob3  immutable  type 

class  ops  [new]  instance  ops  [ins,  waiting?,  next] 

based  on  sort  C  from  Set  with  [Int  for  T] 

%  new,  ins,  waiting?  empty?  as  in  Mob  and  Mob2. 

ndop  next(m:Mob3)  returns(i:Int)  signals(empty(Null)) 
requires 
effect  i  €  m 

operation  to  signal,  like  the  next  operation  of  Mob2.  Therefore,  the  next  operation  of 
Mob3  can  return  any  element  of  the  carrier  set  of  OneOf  [normal :  Int,  empty:  Null] 
when  the  requires  clause  is  not  satisfied. 

Let  M3  be  a  specification  that  combines  the  types  Mob2  and  Mob3.  Let  <  be  the 
smallest  reflexive  relation  on  the  types  of  M3  such  that  Mob2  <  Mob3.  Let  OBS  be  the 
following  set  of  NOAL  programs,  where  x  :  Mob  and  i  :  Int 

{waiting?(x,  i),  empty?(x),  next(x)}. 

Then  <  is  a  subtype  relation  with  respect  to  OBS.  This  is  another  instance  of  a  subtype 
being  more  defined  than  its  supertypes. 

We  can  also  show  that  the  type  Mob,  which  h2is  fewer  exceptional  results,  is  a  subtype 
of  Mob3.  Let  M4  be  a  specification  that  combines  the  types  Mob  and  Mob3. 

To  understand  why  Mob  is  a  subtype  of  Mob3  we  need  to  understand  the  subtype 
relationships  on  the  OneOf  types  that  we  use  to  model  exceptions. 

A  specification  of  the  type  OneOf  [normal :  Int ,  empty:  Null]  is  given  in  Figure  5.5, 
where  the  type  name  is  abbreviated  to  NE  and  we  have  taken  the  liberty  of  using  special 
syntax  for  defining  the  set  of  instance  operations  named  value  [T]  for  types  T.  The  trait 
used  to  define  the  carrier  set  and  trait  functions  of  this  type  is  found  in  Figure  2.7  on 
page  40.  The  specification  of  OneOf  [normal:  Int]  is  similar. 

There  are  other  ways  to  specify  OneOf  types  so  that  OneOf  [normal :  Ipt]  is  a  subtype 
of  OneOf  [noruial : Int ,  empty: Null].  We  could  include  in  our  programming  language 
built-in  expressions  for  observing  OneOf  instances  [LAB*S1,  Section  1 1.6]  [CW85]  [CarS4]. 


Figure  5.5:  Specification  of  the  type  NE  =  OneOf[normal:  Int,  empty:  Null]. 

NE  immutable  type 

class  ops  [makejiormal,  makejempty] 
instance  ops  [hasTag?,  value[7’]] 
based  on  sort  NE  from  OneOf[normal:  Int,  empty:  Null] 

op  make_normal(c:NEClass,  i:  Int)  returns{o:NE) 
effect  o  =  make_normaJ(i) 

op  make^mpty(c:NEClass,  n:  Null)  return8(o:NE) 
effect  o  =  make_empty(n) 

op  hasTag?(o:NE,  t:  Tag)  returns(b:Bool) 
effect  b  =  h2isTag?(o,  t) 

op  value[T](o:NE,  t;  Tag)  returns(r:r) 
requires  hasTag?(o,  t) 

&  ((t  =  normal)  =»  Int  =  T) 

&  ((t  =  empty)  =»  Null  =  T) 
effect  ((t  =  normal)  r  =  val_normal(o)) 

&  ((t  =  02)  r  =  valjempty(o)) 
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We  could  specify  value-ni  operations  for  each  tag  ni,  and  limit  the  set  of  observations  so 
that  each  value-ni  operation  can  only  be  invoked  on  instances  that  are  known  to  have  the 
tag  ni  [vWMP*77].  These  choices  lead  to  the  appropriate  subtype  relationship,  since  they 
all  allow  an  observation  intended  for  an  instance  of  OneOf  [normal :  Int ,  empty :  Null]  to 
be  applied  to  an  instance  of  OneOf  [normal :  Int]  without  surprises.  The  alternative  we 
have  adopted  has  the  advantage  of  allowing  OneOf  types  to  be  specified  without  adding 
special  features  to  a  programming  language. 

Let  <  be  the  smallest  reflexive  relation  on  the  types  of  M4  such  that  Mob  <  Mob3  and 

OneOf  [normal  :  Int]  <  OneOf[normal  ;  Int,  empty  :  Null). 

Let  OBS  be  the  following  set  of  NOAL  programs,  where  x  :  Mob3,  i  :  Int,  o  ; 
OneOf  [normal  ;  Int,  empty  :  Null],  and  t  :  Tag, 

waiting?(x,  i),  empty?(x),  value[lnt](next(x),  normal), 
hasTag?(o,  t),  value[Int](o,  normal) 

Let  C  be  an  M4-algebra  and  let  ijc  €  ENV [X ,C)  be  an  environment  that  obeys  <.  Let 
A  be  an  M4-algebra  with  the  same  carrier  sets  and  abstract  functions  as  C  but  with 
a  maximally  nondeterministic  nextMobs— int  operation.  Define  the  environment  rf^  € 
ENV {X ,  A)  cis  follows.  If  ?7c(x)  is  a  proper  instance  of  Mob,  then  let  77^ (x)  be  an  instance 
of  Mob3  in  A  with  the  same  elements;  that  is,  for  all  j  6  C'#6#('?c(x))i)  is  true  if 

and  only  if  A^e#(^/i(x)>  j)  holds.  If  rjoio)  is  a  proper  instance  of  OneOf  [normal :  Int] , 
then  let  7^(0)  be  an  instance  of  OneOf  [normal :  Int ,  empty:  Null]  in  A  with  the  same 
tag  (normal)  and  value.  Otherwise  for  all  y  €  F,  let  »7/i(y)  =  »7c(y)-  It  is  straightforward 
to  show  that  {C^rjc)  imitates  (A, 77^)  with  respect  to  OBS.  Thus  <  is  a  subtype  relation 
on  the  types  of  M4  with  respect  to  OBS. 

In  general  a  subtype  (such  as  Mob)  can  have  fewer  exceptions  than  its  supertypes 
(such  as  Mob3),  because  a  OneOf  type  with  fewer  tags  can  be  a  subtype  of  a  OneOf  type 
with  the  same  tags  and  more  (as  noted  by  Cardelli  [Car84]). 

5.3.5  Virtual  Supertypes 

In  many  practical  examples  of  object-oriented  design,  one  specifies  types  without  class 
operations  to  be  used  as  supertypes.  Since  these  types  do  not  have  class  operations  they 
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Figure  5.6:  The  specification  Vehicles,  including  types  Vehicle  and  Bicycle. 

Vehicle  virtual  type 

instance  ops  [wheels,  passengers] 

based  on  sort  C  from  Vehicle 

op  wheels(v. Vehicle)  returns(i:Int) 
effect  i  =  wheels  (v) 

op  passengers(v:Vehicle)  returns(i:Int) 
effect  i  =  passengers(v) 

Bicycle  immutable  type 

class  ops  [new]  instance  ops  [wheels, passengers, maker] 

based  on  sort  String  from  CharString 

op  makefBicycleClass,  s:String)  returns(b:Bicycle) 
effect  b  =  s 

op  wheels(b:Bicycle)  returns(i:Int) 
effect  i  =  2 

op  passengers(b: Bicycle)  returns(i:Int) 
effect  i  =  1 

op  maker(b: Bicycle)  returns(s:String) 
effect  s  =  b 


cannot  be  instantiated.  We  call  a  type  that  cannot  be  instantiated  a  virtual  type,  since  its 
implementations  often  use  virtual  operations.  A  virtual  operation  has  an  implementation 
that  uses  some  primitive  (called  virtual  in  Simula  67  [DMN70]  [BDMN73])  to  invoke 
an  operation  of  a  subclass  hence  a  virtual  operation  cannot  be  executed  unless  the 
subclass  has  defined  the  required  operation. 

Consider  the  specification  Vehicles,  given  in  Figure  5.6.  In  this  specification.  Vehicle 
is  a  virtual  type  and  has  no  class  operations.  The  carrier  set  for  Vehicle  is  described  in 
the  trait  Vehicle  found  in  Figure  5.7. 

We  will  now  show  informally  that  the  smallest  reflexive  relation  <  on  the  types  of 

researchers  (e.g.,  [SC\V85,  Page  42]  [Sym84,  Page  450])  call  a  type  or  class  that  cannot  be 
instantiated  “abstract,”  but  this  leads  to  confusion  with  the  term  “abstract  data  type.” 
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Figure  5.7:  The  trait  Vehicle  that  describes  the  abstract  values  of  Vehicle. 

Vehicle  trait 
introduces 

wheels:  C  —*■  Int 
passengers:  C  — ♦  Int 
asserts  for  all  [u:  C] 
wheels(u)  >  1 
passengers(u)  >  1 


Vehicles  such  that  Bicycle  <  Vehicle  is  a  subtype  relation  with  respect  to  the  set  of 
observations  OBS  defined  by  the  NOAL  programs  wheels  (x)  and  passengers  (x),  where 
X  has  nominal  type  Vehicle.  Let  C  be  a  Vehicles-algebra  and  let  rjc  6  ENV(X,  C)  be  an 
environment  that  obeys  <.  Let  A  be  a  Vehicles-algebra  with  the  same  carrier  set  for  all 
types  as  C,  except  that  we  add  an  element  q  to  the  carrier  set  of  Vehicle  if  necessary  with 

the  property  that  A,yheeu(9)  =  2  and  Ap _ =  1-  We  define  a  nominal  environment 

tja  €  ENV(X,A)  as  follows.  Suppose  qci^)  *  proper  element  of  type  Bicycle;  then 
let  tia{^)  be  the  instance  q  €  Avehicie  that  by  assumption  is  such  that  Awheeis(v)  =  2  and 
ApaanengeniCg)  =  1-  Otherwise,  for  all  other  y  €  A,  let  ^^(y)  =  Vciv),  which  makes  sense, 
since  the  carrier  sets  for  C  are  subsets  of  those  for  A.  Then  (C,  qc)  imitates  (A,  q^)  with 
respect  to  OBS,  because  if  qc  maps  the  identifier  x  of  nominal  type  Vehicle  to  a  proper 
instance  of  type  Bicycle,  then 


/A[wheels(x)|(C,T7c)  = 

{2} 

(5.17) 

Af[passengers(x)|(C,  7c)  = 

{1} 

(5.18) 

M  (wheels(x)](  A,  q^)  = 

{2} 

(5.19) 

Ad(passengers(x)](A,7^)  = 

{!}• 

(5.20) 

So  Bicycle  is  a  subtype  of  Vehicle. 

5.4  Other  Definitions  of  Subtype 

In  this  section  we  compare  our  definition  of  subtype  relations  with  other  notions  of 
subtyping. 

The  major  difference  is  that  our  definition  is  bcised  on  the  semantics  of  abstract  data 
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types,  which  allows  us  to  deal  with  incompletely  specified  types  and  with  nondeterministic 
types.  The  only  other  formal  treatment  of  subtype  relationships  that  deals  with  abstract 
data  types  is  the  work  of  Bruce  and  Wegner,  which  is  discussed  below.  Even  informal 
discussions  of  subtype  relationships  have  largely  ignored  incompletely  specified  types. 

Another  difference  is  that  our  definition  of  subtype  relations  explicitly  takes  into 
account  a  set  of  observations.  This  is  a  feature  of  some  work  on  observational  equivalence 
(e.g.,  [ST85]),  but  does  not  appear  in  other  work  on  subtyping. 

5.4.1  Informal  Definitions  of  Subtype  Relationships 

Schaffert  et  al.  offer  the  following  informal  definition  of  a  subtype  relationship;  “Given 
a  type  S  which  is  a  subtype  of  a  type  T,  then  any  object  of  type  S  behaves  like  a  T  object 
and  may  be  used  wherever  a  T  object  may  be  used”  [SCB*86,  Section  5].  For  types 
that  are  not  incompletely  specified,  this  definition  seems  to  agree  with  our  definition 
of  subtyping.  We  will  make  this  connection  more  formally  in  the  next  chapters,  where 
we  study  imitation  and  simulation  relations  between  objects.  However,  for  incompletely 
specified  types  a  simple  relation  on  objects  does  not  suffice  to  prove  a  subtype  relation, 
as  we  showed  above  for  the  types  PSchd  and  Crowd.  In  that  example,  each  PSchd  object 
acts  like  some  Crowd  object,  but  PSchd  is  not  a  subtype  of  Crowd. 

Snyder  [SnySGb,  Page  41]  offers  the  following  definition  of  a  subtype  relationship:  “If 
instances  of  class  x  meet  the  external  interface  of  class  y,  then  x  should  be  a  subtype  of 
y.”  By  “external  interface”  Synder  means  a  behavioral  specification;  thus  his  definition  of 
subtype  relationships  is  also  a  semantic  relationship  between  instances.  For  example,  he 
says  that  “behavioral  subtyping  cannot  be  deduced  without  formal  semantic  specification 
of  behavior.”  However,  he  goes  on  to  say  that  “lacking  such  specifications,  one  can  deduce 
subtyping  based  solely  on  syntactic  external  interfaces  (i.e.,  the  names  of  the  operations) 
[Car84].”  We  strongly  disagree  with  this  latter  statement,  since  for  valid  reasoning  based 
on  subtype  relationships  among  abstract  types,  the  semantics  of  a  type  must  be  taken  into 
account.  For  example,  consider  a  type  IntPairLoop,  which  is  like  IntPair  except  that  its 
second  operation  goes  into  an  infinite  loop  when  called.  IntPairLoop  is  not  a  subtype  of 
IntPair,  although  the  two  types  have  compatible  syntactic  interfaces.  Although  Snyder 
cites  Cardelli’s  paper  [Car84]  to  support  his  statement,  Cardelli’s  syntactic  deductions 
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do  not  apply  to  abstract  types  in  general,  but  only  to  a  limited  set  of  types  (as  we  discuss 
below). 


5.4.2  Cardelli’s  “Semantics  of  Multiple  Inheritance” 

Cardelli’s  “A  Semantics  of  Multiple  Inheritance”  [Car84]  describes  subtype  relationships 
among  the  built-in  types  of  a  small  programming  language,  as  well  as  its  type  checking 
eind  semantics.  Unlike  our  definition  of  subtype  relations,  Cardelli’s  paper  does  not  deal 
with  abstract  data  types.  Since  Cardelli  only  deals  with  a  fixed  set  of  built-in  types,  he 
is  able  to  give  simple  syntactic  rules  that  determine  when  one  of  these  types  is  a  subtype 
of  another  type. 

Cardelli  makes  no  claim  that  his  syntactic  rules  extend  to  abstract  types.  He  only 
shows  that  his  syntactic  subtyping  rules  are  sound  in  the  sense  that  they  prevent  certain 
errors  in  progr2uns  written  his  language.  Cardelli  writes  S  <  T  when  S  is  syntactically  a 
subtype  of  T.  The  semantics  of  Cardelli’s  language  are  described  using  a  domain  V.  This 
domain  is  constructed  so  that,  whenever  S  <  T,  then  the  carrier  set  of  S  is  a  subset  of  the 
carrier  set  of  T  [Car84,  Page  62].  This  supports  inclusion  polymorphism  without  generic 
invocation,  since  the  instance  operations  of  the  built-in  types  of  Cardelli’s  language  work 
on  all  subsets  of  their  domains,  and  hence  on  all  subtypes. 

We  can  regard  Cardelli’s  V  as  the  only  “algebra”  in  the  semantics  of  a  specification  of 
the  built-in  types  of  his  language,  although  it  is  not  technically  one  of  our  algebras.  An 
expression  written  in  his  language  defines  a  (deterministic)  observation  of  V.  Because  of 
the  way  that  V  is  constructed,  all  environments  whose  range  is  V  that  obey  the  relation 
<  are  also  nominal  environments.  (That  is,  if  t}{x)  has  type  S  and  x  has  nominal  type 
T,  then  S  <  T,  which  means  that  V3  C  Vx,  and  so  r){x)  also  has  type  T.)  Since  every 
algebra-environment  pair  imitates  itself  with  respect  to  all  sets  of  observations  written  in 
his  language,  Cardelli’s  <  is  a  subtype  relation  (in  our  sense)  with  respect  to  all  sets  of 
observations  written  in  his  language.  So  our  definition  of  subtype  relations  is  compatible 
with  Cardelli’s.  The  differences  are  that  Cardelli  considers  function  types,  which  are  not 
ecisily  modeled  by  our  algebras,  and  our  algebras  can  model  abstract  data  types,  and 
nondeterministic  types,  which  Cardelli  does  not  handle. 
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5.4.3  Bruce  and  Wegner’s  Definition  of  Subtyping 

The  work  that  comes  closest  to  our  own  is  that  of  Bruce  and  Wegner  [BW87].  In  this 
subsection  we  show  that  our  definition  of  subtype  relations  is  more  general  them  theirs 
and  point  out  a  failing  of  their  definition. 

Our  definition  is  more  general  than  Bruce  and  Wegner’s  for  two  reasons.  First,  our 
definition  handles  nondeterministic  and  incompletely  specified  types,  whereas  Bruce  and 
Wegner  only  deal  with  a  single  deterministic  algebra.  Second,  Bruce  and  Wegner  do 
not  define  subtype  relations  with  respect  to  a  set  of  observations.  Bruce  and  Wegner’s 
definition  does  not  even  focus  on  the  observable  behavior  of  an  algebra;  instead  they 
define  subtype  relations  with  the  aid  of  a  family  of  homomorphic  functions  between  the 
carrier  sets  of  an  algebra.  Since  the  existence  of  a  homomorphic  function  is  a  strong 
condition,  using  Bruce  and  Wegner’s  definition  of  subtype  relations  would  exclude  some 
subtype  relations  that  our  definition  would  allow.  As  we  will  illustrate  below,  Bruce 
and  Wegner’s  definition  fails  to  show  a  subtype  relationship  between  two  types  that  are 
observably  equivalent.  In  Chapter  6  we  show  that  certain  homomorphic  relations  can  be 
used  to  prove  subtype  relationships.  Because  homomorphic  functions  are  a  special  case 
of  homomorphic  relations,  Bruce  and  Wegner’s  definition  is  not  as  general  as  ours. 

In  the  rest  of  this  subsection  we  show  how  Bruce  and  Wegner’s  definition  fails  to  show 
a  subtype  relationship  between  two  types  that  are  observably  equivalent.  We  show  this 
with  an  example  adapted  from  a  paper  by  Mitchell  [Mit86,  Page  266].  In  this  exaniple, 
the  types  SI  and  S2  represent  multi-sets  of  integers.  Bruce  and  Wegner  do  not  tell  us  how 
to  model  specifications,  so  we  simply  consider  an  algebra  A,  where  the  elements  of  the 
carrier  set  of  SI  are  lists  (written  [1,2]  below)  of  ordered  pairs  of  the  form  {element,  count) 
and  the  elements  of  the  carrier  set  of  S2  are  just  lists  of  the  elements  inserted  in  the  order 
in  which  they  are  inserted.  Besides  the  class  operations  new  of  types  SI  and  S2  (which 
return  empty  multi-sets  of  types  SI  and  S2  respectively),  each  type  supports  the  instance 
operations  ins  and  count.  To  illustrate  the  representations,  suppose  t;(x)  denotes  the 
result  of  new(S2).  Then  we  have. 


A4[ins(ins(x,5),40)J(A,i/)  =  {[5,40]}. 
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Similarly,  if  r){y)  denotes  the  result  of  new(Sl),  then 

>f[ins(ins(x,5),40)J(A,7;)  =  {[(5, 1),  (40, 1)]}. 

Our  example  exploits  the  differences  in  these  representations.  Let  the  environment  rj 
and  objects  q  and  r  be  such  that 


»7(q)  =  9  T-  =  9(r). 


We  then  have 

A4[ins(ins(ins(new(S2),  q),  r),  q)l(A,  tj) 

=  A4|ins(ins(ins(new(S2),  q),  q),  rjK/l,??) 
although  if  we  use  SI  instead  of  S2  these  are  equal: 


A4(ins(in8(ins(new(Sl),  q),  r),  q)](A,  q) 

=  {[{9,2),{r,l)]} 

=  A4[ins(ins(ins(new(Sl),  q),  q),  r)](/4,  q). 


For  SI  to  be  a  subtype  of  S2  according  to  Bruce  and  Wegner’s  definition,  there  would 
have  to  be  a  homomorphic  function  C(\,2)  from  SI  to  S2.  Because  of  the  structure¬ 
preserving  nature  of  this  function  we  have  the  following  equations,  for  all  environments 
q  such  that  q(q)  =  r  =■  q{T). 


C(i.2)(Af[new(Sl)J(v4,»7))  =  A4lnew(S2)l(A,77)  =  {[]} 
C(i,2)(Af[ins(new(Sl),q)J(A,7/))  =  A4(ins(new(S2),q)I(A,7y)  =  {[9]} 

C(i,2)(-M(ins(ins(new(Sl),q),r)l(A,7/))  =  {[<7.r]} 

C(i,2)(A^[ins(ins(ins(new(Sl),q),r),q)I(A,77))  =  {[9,7-,  9]} 

C(i,2)(Af[ins(ins(new(Sl),q),q)I(A,7/))  =  {[<?,</]} 

C(i,2)(Af[ins(ins(ins(new(Sl),q),q),r)I(A,77))  =  {[9,g,r]} 
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Since  in  77  the  only  possible  result  of  both  ins(ins(ins(new(Sl) ,  q) ,  r)  ,  q)  and 
ins(ins(ins(new(Sl)  ,  q)  ,  q)  ,  r)  is  the  list  of  pairs  [(9,2),  (r,  1)],  C(i  2)  would  have 
to  map  [{q,2),  (r,  1)]  to  both  [q,r,q]  and  Therefore,  C(i,2)  cannot  be  a  function. 

So  Bruce  and  Wegner’s  definition  fails  to  show  a  subtype  relationship  between  ob¬ 
servably  equivalent  types. 


Chapter  6 

Simulation  Relations 


In  this  chapter  we  show  how  to  prove  that  a  binary  relation  is  a  subtype  relation  with 
respect  to  type-safe  NOAL  programs  using  simulation  relationships  among  objects.  We 
also  begin  to  turn  our  attention  from  specification  to  verification,  because  simulation 
plays  a  central  role  in  our  Hoare-style  verification  technique  for  NOAL  programs. 

How  can  one  prove  that  a  binary  relation  on  types  is  a  subtype  relation  with  respect  to 
the  set  of  all  type-safe  NOAL  programs?  Since  the  set  of  all  type-safe  NOAL  programs  is 
infinite,  the  obvious  answer  is  to  use  an  induction  on  the  structure  of  NOAL  expressions. 
The  obvious  induction  hypothesis  is  that  if  one  environment  imitates  another,  then  for 
each  subexpression  E,  each  possible  result  of  E  in  the  first  environment  “imitates”  some 
possible  result  of  E  in  the  second  environm'  nt.  However,  it  is  difficult  to  make  this 
induction  work,  because  imitation  only  directly  constrains  the  possible  results  of  whole 
programs,  not  expressions. 

Since  we  do  not  know  if  the  obvious  induction  hypothesis  can  be  made  to  work,  we 
use  a  more  convenient  hypothesis,  which  may  also  be  stronger.  We  define  a  notion  of 
simulation  that  is  preserved  by  each  NOAL  expression.  So  to  prove  that  a  binary  relation 
on  types  is  a  subtype  relation  we  only  have  to  show  that  each  environment  that  obeys 
the  relation  simulates  some  nominal  environment. 

However,  we  also  want  simulation  to  be  a  more  practical  tool  than  imitation.  So 
simulation  relations  are  defined  cis  relations  between  objects  instead  of  relations  between 
environments.  Furthermore,  we  define  simulation  relations  so  that  one  can  easily  check 
whether  a  relation  among  objects  is  a  simulation  relation.  That  is,  instead  of  checking 
that  a  simulation  relation  is  preserved  by  all  expressions,  one  only  has  to  check  that  it  is 
the  identity  relation  on  instances  of  the  visible  types  (like  Bool  and  Int)  and  that  it  is 
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preserv'ed  by  generic  invocation  expressions. 

For  example,  consider  the  specification  MP  (which  contains  the  types  Mob  and  PSchd 
as  specified  in  Figures  2.6  and  4.2)  and  the  relation  V.  that  is  the  identity  on  instances  of 
Bool  and  Int,  and  that  relates  each  instance  of  PSchd  to  a  maximally  nondeterministic 
instance  of  Mob  with  the  same  set  of  waiting  integers.  This  TZ  relates  the  PSchd  instance 
denoted  by 

ins(ins(new(PSchd,true) , 1) ,2) 
to  a  maximally  nondeterministic  instance  of  Mob  denoted  by 
ins(ins(new(Mob) , 1) ,2)  . 

We  check  that  this  relationship  is  preserved  by  each  generic  invocation  in  the  following 
manner. 

•  For  the  generic  operation  empty?,  the  only  possible  result  on  the  PSchd  instance  is 
false,  which  is  also  the  only  possible  result  on  the  Mob  instance. 

•  For  the  generic  invocation  next,  the  only  possible  result  on  the  PSchd  instance  is 

1,  which  is  related  by  7^2.  to  1,  and  1  is  a  possible  result  on  the  Mob  instance.  ! 

I 

I 

•  For  all  integers  i,  the  only  possible  result  of 

waiting?(ins(ins(new(PSchd,true) , 1) ,2) , i) 
is  related  by  TZ  to  the  only  possible  result  of 
waiting? (ins (ins (new (Mob) ,1) ,2) ,i)  . 

•  Furthermore,  for  all  integers  j,  the  result  of 

ins(ins(ins(new(PSchd,true) , 1) ,2) , j) 
is  related  by  TZ  to  the  result  of 

ins(ins(ins(new(Mob) , 1) ,2)  , j), 
since  both  have  the  same  set  of  waiting  integers. 
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In  this  example  we  have  checked  only  that  72^  is  preserved  by  the  instance  operations 
of  type  Mob.  We  did  not  check  the  PSchd  instance  operation  leastFirst,  because 
leastFirst  cannot  be  applied  to  an  expression  of  nominal  type  Mob. 

In  a  program  that  uses  inclusion  polymorphism,  instances  of  a  subtype  can  be 
treated  as  if  they  were  instances  of  a  supertype.  For  example,  suppose  x  and  y  are 
identifiers  of  nominal  type  Mob  that  denote  the  PSchd  instances  new(PSchd,truG)  and 
new(PSchd, false)  (respectively).  We  can  apply  only  the  instance  operations  of  type 
Mob  to  these  identifiers  in  a  type-safe  NOAL  program;  therefore  the  values  of  x  and  y 
cannot  be  distinguished  by  a  type-safe  program.  However,  if  x  and  y  had  type  PSchd, 
we  could  also  apply  the  operation  leastFirst,  which  would  distinguish  them.  That  is, 
viewed  as  instances  of  Mob,  these  instances  simulate  each  other,  but  viewed  as  instances 
of  PSchd  neither  simulates  the  other.  Therefore,  in  our  formal  treatment  of  simulation  a 
simulation  relation  is  a  family  of  relations,  one  per  type,  so  that  we  can  keep  the  simu¬ 
lation  relationships  for  each  view  straight.  For  example,  we  say  that  newfPSchd.true) 
simulates  new(PSchd, false)  at  type  Mob,  but  this  relationship  does  not  hold  at  type 
PSchd. 

To  prove  that  a  binary  relation  <  is  a  subtype  relation,  we  need  a  simulation  relation 
such  that  whenever  S  <  T,  then  each  instance  of  type  S  is  related  to  some  instance  of 
type  T  at  type  T.  Such  simulation  relations  are  said  to  witness  the  relation  <.  If  we 
have  a  simulation  relation  that  witnesses  <,  then  from  every  environment  that  obeys  < 
we  can  build  a  nominal  environment  that  the  first  environment  imitates.  The  nominal 
environment  is  built  by  replacing  each  binding  of  an  instance  q  of  type  S  to  an  identifier 
of  nominal  type  T  where  S  <  T  with  a  binding  of  an  instance  r  of  type  T  such  that  q 
simulates  r  at  type  T. 

We  also  use  simulation  relations  that  witness  a  subtype  relation  during  the  verifi¬ 
cation  of  NOAL  programs,  where  such  simulation  relations  are  used  to  coerce  objects 
from  subtypes  to  supertypes.  For  example,  consider  the  following  call  to  the  function 
is2waiting,  which  is  specified  in  Figure  4.1: 

is2waiting(new(PSchd,true)) . 

From  the  specification  of  PSchd,  we  can  conclude  that  if  x  :  PSchd  denotes  the  result  of 
new(PSchd,true),  then  (2  €  x. second)  =  false.  The  specification  of  is2waiting  has  a 
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description  of  the  function’s  effect  written  using  the  trait  functions  of  type  Mob  (it  says 
that  the  result  is  2  G  m,  where  m  :  Mob  is  the  formal  argument).  So  to  find  the  effect 
of  the  call  we  note  that  new(PSchd,true)  simulates  new(Mob)  at  type  Mob  and  that  if 
m  ;  Mob  denotes  new(Mob),  then  (2  G  m)  =  false.  Details  appear  in  Chapter  7. 

In  the  rest  of  this  chapter  we  give  a  formal  definition  of  simulation  relations,  show 
that  simulation  is  preserved  by  NOAL  expressions,  discuss  how  simulation  relations  can 
be  used  to  prove  that  a  binary  relation  on  types  is  a  subtype  relation,  and  give  several 
examples  of  such  proofs. 

6.1  Definition  of  Simulation  Relations 

In  this  section  we  give  a  formal  definition  of  simulation  relations  and  compare  simulation 
relations  with  some  related  concepts. 

We  call  a  family  of  relations,  which  has  one  binary  relation  between  the  carrier  sets 
of  two  algebras  per  type,  a  typed  family  of  relations. 

Definition  6.1.1  (typed  family  of  relations).  Let  E  =  {TYPES,  V,  TFUNS,  OPS) 
be  a  signature.  A  typed  family  of  relations,  71,  between  S-algebras  C  and  >4  is  a  set  of 
binary  relations  on  the  carrier  sets  of  C  and  A  indexed  by  TYPES: 

7t  =  {TZj  C  {Ctypes  X  Ajypes)  1  T  ^  TYPES) 

Each  TZr  may  relate  objects  of  types  other  than  T  and  may  also  relate  objects  having 
different  types.  For  example,  T^Mob  may  related  two  instances  of  PSchd  or  an  instance  of 
PSchd  to  an  instance  of  type  Mob. 

To  find  whether  an  environment  is  related  by  a  typed  family  of  relations  to  some 
othf^r  ^environment,  we  use  the  nominal  type  of  each  identifier  to  select  the  appropriate 
relation,  T^t-  That  is,  given  environments  rji  G  ENV{X ,C)  and  r]2  €  ENV{X ,  A),  we 
write  Til  7Z  7^2  when  for  all  types  T  and  for  all  identifiers  x  :  T  ^  X ,  rji{x)  Ttr  r)2{x). 

For  notational  convenience,  we  also  use  the  following  abbreviations  when  dealing  with 
a  typed  family  of  relations,  7Z,  and  the  binary  relations  TZi. 

•  Given  subsets  Q  C  Ctypes  and  R  C  Atypes-,  we  write  QTl-r  R  when  for  all  q  €  Q, 
there  is  some  r  G  /?  such  that  q  TZj  r.  We  often  use  this  notation  when  comparing 
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sets  of  possible  results  and  the  carrier  sets  of  the  various  types.  For  example, 
Cs  .i4t  means  that  for  each  instance  q  of  type  S  in  the  algebra  C,  there  is  an 
instance  r  of  type  T  in  A  such  that  q  r. 

•  Given  a  tuple  f  of  types  and  two  tuples  of  objects  the  same  length  q  and  r,  we 
write  qlZ^  r,  when  for  each  i,  r,. 

We  also  use  vector  notation  for  tuples  of  variables  and  expressions.  We  also  write 
Tj{x)  for  the  tuple  of  the  values,  (. . .  ,t;(x,),  . . .). 

There  are  four  properties  that  characterize  when  a  typed  family  of  relations  is  a  sim¬ 
ulation  relation.  First,  a  simulation  relation  is  preserved  by  each  generic  invocation;  we 
call  such  a  typed  family  of  relations  a  “homomorphic  relation  for  NomSig  and  <,”  since 
the  set  of  generic  invocations  and  their  nominal  types  are  determined  by  a  nominal  sig¬ 
nature  map  NomSig  and  a  presumed  subtype  relation  <.  Second,  a  simulation  relation 
must  be  the  identity  on  the  visible  types;  we  call  such  relations  “V-identical.”  Third,  a 
simulation  relation  must  preserve  the  meaning  of  J.;  we  call  such  a  relation  “bistrict.” 
Finally,  the  relationships  at  each  subtype  must  hold  at  each  supertype.  The  last  prop¬ 
erty  has  a  largely  technical  motivation,  but  it  embodies  the  intuition  that  if  one  object 
simulates  another  at  a  subtype,  then  this  simulation  relationship  should  hold  at  each 
supertype,  since  no  other  generic  operations  will  be  applicable  at  the  supertype. 

We  give  the  formal  definition  of  these  terms  after  presenting  our  definition  of  simula¬ 
tion  relations. 

Definition  6.1,2  (simulation  relation).  Let  E  be  a  signature.  Let  fVom5i5f  be  a  nom¬ 
inal  signature  map.  Let  <  be  a  binary  relation  on  the  types  of  S.  Let  C  and  A  be 
E-algebras.  A  simulation  relation  between  C  and  A  for  NomSig  and  <  is  a  homomorphic 
relation  between  C  and  A  for  NomSig  and  <  that  is  V-identical,  bistrict  and  such  that 
for  all  types  S  and  T, 

(S  <  T)  =»  {Us  C  TIt)  (6.1) 

The  definition  of  a  homomorphic  relation  formalizes  the  notion  that  the  relation  at 
each  type  is  preserved  by  each  generic  invocation  that  is  applicable  to  expressions  of  that 
type. 
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Definition  6.1.3  (homomorphic  relation).  Let  E  =  {TYPES,  V,  TFUNS,OPS)  be 
a  signature.  Let  NomSig  be  a  nominal  signature  map  whose  domain  is  a  set  GOP  of 
generic  operation  symbols.  Let  <  be  a  presumed  subtype  relation.  A  typed  family  of 
relations,  TZ,  between  S-algebras  C  and  A  is  a  homomorphic  relation  between  C  and  A  for 
NomSig  and  <  if  and  only  if  for  all  sets  of  typed  identifiers  X ,  whenever  t}i  G  ENV{X ,C) 
and  t/2  G  ENV{X ,  A)  are  such  that  iji  'R  7/2?  then  for  all  T  G  TYPES,  for  all  generic 
operation  symbols  g  G  GOP,  and  for  all  identifier  lists  x  :  S  G  A  such  that  the  nominal 
type  of  g(x)  is  T, 

^  [g(x)l(  A,  7/2).  (6.2) 

Formula  6.2  says  that  every  possible  result  of  Al|g(x)I(C',  7/1)  is  related  by  TZj  to  some 
possible  result  of  Ad(g(x)J(A,7;2). 

We  sometimes  omit  mention  of  the  algebras,  NomSig,  and  <  when  they  are  not 
important  or  are  clear  from  context. 

In  the  definition  above,  the  identifier  li.st  x  may  be  empty.  Therefore,  if  7?.  is  a 
homomorphic  relation  between  C  and  A,  then  for  all  nullary  generic  operation  symbols 
(i.e.,  type  symbols)  T  G  GOP  such  that  the  nominal  type  of  T()  is  TClass,  and  for  all 
environments  771  and  772, 

>flT()l(C,77,)7^TCias»><[T()l(A,772).  (6.3) 

This  follows  because  the  denotation  of  the  expression  T()  does  not  depend  on  an  envi¬ 
ronment,  and  furthermore  if  rji  G  ENV(0,C)  and  772  G  ENV{0,A),  then  by  definition 
771  7^772.  So  if  there  are  nullary  generic  operation  symbols  in  the  domain  of  NomSig,  then 
a  homomorphic  relation  for  NomSig  and  <  cannot  be  empty. 

A  trivial  example  of  a  homomorphic  relation  between  an  algebra  A  and  itself  is  the 
typed  family  of  equality  relations  on  the  carrier  sets  of  A.  A  trivial  example  of  a  homo¬ 
morphic  relation  between  two  algebras  C  and  A  is  the  typed  family  of  relations  each  of 
which  relates  every  object  in  the  carrier  set  of  C  to  every  object  in  the  carrier  set  of  A. 
We  require  that  simulation  relations  be  V-identical  and  bistrict  so  that  this  “complete” 
homomorphic  relation  not  a  simulation  relation. 

Unless  it  preserves  the  meaning  of  the  visible  types,  a  homomorphic  relation  embodies 
a  poor  notion  of  “simulation.”  The  following  definition  describes  what  we  mean  by 
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preserving  the  meaning  of  the  visible  types.  The  definition  makes  sense  because  we  have 
assumed  that  the  same  reduct  that  defines  the  visible  types  is  used  in  each  algebra. 

Definition  6.1.4  (V-identical).  Let  E  =  (TYPES,  V,  TFUNS ,  OPS)  be  a  signature. 
Let  C  and  A  be  S-algebras.  Then  a  typed  family  of  binary  relations  7?.  between  the  C 
and  A  is  V-identical  if  and  only  if: 

•  for  each  type  T  6  TYPES,  if  q'/Z^r  and  either  q  or  r  is  a  proper  instance  of  a  visible 
type,  then  q  =  r, 

•  for  each  visible  type  v  £  V ,  contains  the  identity  relation  on  A^,  and 

•  for  each  type  T  G  TYPES  and  for  all  visible  types  u  6  if  there  is  some  proper 
element  q  ^  A^  such  that  q  'R,'^  q,  then  for  all  proper  elements  r  in  Ay,  r  TZ-j  r. 

The  first  condition  says  that  distinct  elements  of  the  visible  types  cannot  be  related.  The 
second  condition  says  that  at  each  visible  type  v,  TZy  is  the  identity  on  the  carrier  set 
of  V.  While  at  first  glance  it  would  seem  better  to  prohibit  IZ^  from  relating  objects 
of  a  visible  type  v  when  T  ^  u,  this  restriction  would  prevent  us  from  using  simulation 
relations  to  prove  that  a  visible  type  is  a  subtype  of  some  other  type.  The  third  condition 
allows  our  proofs  to  work  without  such  restrictions,  although  it  is  somewhat  complex. 

We  also  require  that  a  simulation  relation  preserve  the  meaning  of  X,  which  represents 
nontermination  and  errors  in  our  algebras. 

Definition  6.1.5  (bistrict).  A  binary  relation  is  bistiict  if  and  only  if  X  X  and 
whenever  9  -C  r  and  one  of  q  or  r  is  X,  then  so  is  the  other. 

Note  that  a  bistrict  relation  cannot  be  empty.  We  call  a  typed  family  of  relations  TZ 
bistrict  if  each  TZj  is  bistrict. 

As  an  example  of  a  simulation  relation,  let  NomSig  be  determined  by  the  specification 
IPT  (see  Figure  2.2).  Recall  that  for  this  specification,  the  presumed  subtype  relation  <  is 
the  smallest  reflexive  relation  on  the  types  of  IPT  such  that  IntTriple  <  IntPair.  Let  A 
be  the  algebra  of  Figure  2.5.  Let  TZ  be  the  smallest  bistrict  typed  family  of  relations  such 
that  for  all  types  T,  if  <7  G  Aj,  then  qTZiq,  and  for  all  {91,92,93),  (91,92,94)  6  AintTripie 
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and  (91,92)  G  >llntPalr, 


^IntPair 

{fluQ2) 

(6.4) 

"^latPair 

(91,92,93) 

(6.5) 

(91,92,93) 

^latPair 

(91,92,94)- 

(6.6) 

Then  7^  is  a  simulation  relation  for  NomSig  and  <.  By  construction,  It  is  bistrict,  V- 
identical,  and  relationships  at  type  IntTriple  hold  at  type  IntPair.  To  show  that  It  is 
a  homomorphic  relation  for  NomSig  and  <,  let  X  and  environments  91,92  €  ENV {X ,  A) 
be  such  that  T]iTtg2-  Suppose  g(x)  is  a  generic  invocation  of  some  nominal  type  T.  If  none 
of  the  identifiers  in  x  have  nominal  type  IntPair,  then  by  construction  91  (it)  =  92(it) 
and  thus  A^[g(x)](yl,  91)  =  A^[g(x)l(A,92);  since  each  Tit  contains  the  identity  relation 
on  At,  it  follows  that  *M|g(x)l(/l,9i)  Itj  -M[g(x)](A,92).  The  only  generic  operation 
symbols  that  can  take  an  argument  of  nominal  type  IntPair  are  first  amd  second. 
Suppose  X  has  nominal  type  IntPair,  then  since  9i(x)7^intPair  92(x),  the  first  and  second 
components  of  91  (x)  auid  92(x)  must  be  the  same  if  they  Me  proper  objects.  Therefore 
we  have: 


Ad[first(x)](A,9i)  =  Ad[f  ir8t(x)l(i4,92)  (6.7) 

A<[second(x)](/4,9i)  =  A^[second(x)J(/4, 92).  (6.8) 

So  this  7^  is  a  homomorphic  relation. 

A  homomorphic  relation  has  a  substitution  property:  each  generic  invocation  maps 
related  arguments  to  related  results  (Formula  6.2).  Moreover,  the  possible  results  of  a 
generic  invocation  g(x)  are  related  by  T^x,  where  the  nominal  type  of  g(x)  is  T.  This 
substitution  property  is  the  key  to  our  inductive  proof  that  simulation  is  preserved  by 
all  type-safe  NOAL  expressions. 

The  substitution  property  is  similar  to  the  defining  property  of  Nipkow’s  simulation 
relations  [Nip86].  The  difference  is  that  we  provide  for  generic  invocation  mechanisms 
and  allow  objects  of  one  type  to  be  related  to  objects  of  another  type. 

A  substitution  property  is  also  used  to  define  homomorphisms  between  multisorted 
algebras  [Gra79,  Page  35].  Our  homomorphic  relations  differ  from  the  usual  homomor¬ 
phisms  between  multisorted  algebras  [EM85]  in  two  ways:  they  are  relations  instead  of 
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functions,  and  they  may  relate  objects  of  one  type  to  objects  of  another  type.  Neverthe¬ 
less,  it  is  appropriate  to  call  homomorphic  relations  “homomorphic,”  because  they  have 
a  substitution  property  and  they  can  be  composed.  (The  composition  of  homomorphic 
relations  is  just  the  usual  product  of  relations  at  each  type.) 

Simulation  relations  are  also  similar  to,  but  more  general  than,  the  coercer  functions 
that  form  the  basis  of  Bruce  and  Wegner’s  definitions  of  subtype  relations  [BW87]. 

Homomorphic  relations  also  resemble  the  “logical  relations”  used  in  the  study  of  the 
lambda  calculus  [Sta85]  [Mit86].  An  important  property  of  logical  relations  is  captured 
by  the  so-called  fundamental  theorem  of  logical  relations  [Sta85].  In  the  next  section  we 
state  and  prove  our  version  of  the  fundamental  theorem  (which  is  Theorem  6.2.3). 

6.2  Simulation  as  a  Criterion  for  Imitation 

In  this  section  we  show  that  simulation  is  preserved  by  all  type-safe  NOAL  expressions. 
That  is,  the  substitution  property  holds  for  NOAL  expressions  and  programs  as  well  as 
generic  invocations.  This  allows  us  to  conclude  that  if  72.  is  a  simulation  relation  for 
NomSig  and  <  and  72  relates  two  environments,  then  the  first  environment  imitates  the 
second  with  respect  to  the  set  of  type-safe  NOAL  programs  over  NomSig  and  <.  This 
result  is  used  in  the  next  section  in  our  technique  for  showing  that  a  binary  relation  on 
types  is  a  subtype  relation. 

Our  strategy  is  sa  follows.  We  first  show  that  simulation  is  preserved  by  all  NOAL 
expressions.  Since  simulation  relations  are  V-identical  and  bistrict,  and  since  type-safe 
programs  have  visible  type,  it  follows  that  simulation  can  be  used  as  a  criterion  for 
imitation.  To  show  the  desired  result  for  NOAL  expressions,  we  first  assume  that  the 
denotations  of  each  free  function  identifier  in  the  two  algebras  are  related  by  72  (in  a  way 
we  describe  below).  We  then  show  (in  Appendix  C)  that  the  two  meanings,  one  for  each 
algebra,  of  a  system  of  recursively  defined  function  identifiers  are  properly  related. 

Since  NOAL  “functions”  can  be  nondeterministic,  their  denotations  are  operations 
(i.e.,  set-valued  functions).  We  compare  operations  by  analogy  to  the  definition  of  logical 
relations  [Sta85]  [Mit86].  That  is,  if  72  is  a  typed  family  of  relations,  then  we  extend  72 
to  the  signatures  of  NOAL  function  identifiers  as  follows: 

{(/i,/2)  I  qTl,f^  /i(7)  72,  /2(r)}  . 


(6.9) 
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That  is,  for  all  operations  /i  and  /j,  fi  is  related  by  to  if  and  only  if  whenever 

qTZ?  r,  then  for  every  q'  G  /i(^,  there  is  some  r'  G  /aCO  such  that  q'  7Z„  r' .  Notice  that 
this  extension  of  %  preserves  the  substitution  property  of  simulation  relations.  Since  op¬ 
erations  are  not  first-class  objects  in  NOAL,  we  need  not  be  concerned  that  this  extension 
has  all  the  properties  of  a  simulation  relation  at  each  function  signature. 

To  deal  with  NOAL  expressions  that  have  free  function  identifiers,  we  allow  envi¬ 
ronments  to  map  typed  function  identifiers  to  operations  (i.e.,  to  relations  that  denote 
recursively  defined  NOAL  functions). 

For  brevity,  throughout  the  rest  of  this  section  we  establish  the  following  conventions. 

S  =  {SORTS,  TYPES,  V,  TFUNS,  OPS)  is  a  signature. 

A  and  B  are  E-algebras. 

NomSig  is  a  nominal  signature  map. 

GOP  is  the  domain  of  NomSig,  a  set  of  generic  operation  symbols. 

<  is  a  binary  relation  on  type  symbols. 

Recall  that  NomSig  and  <  can  be  used  to  determine  the  nominal  type  of  a  NOAL  program 
or  expression,  if  one  exists. 

6.2.1  The  Substitution  Property  for  NOAL  Expressions 

Informally,  the  following  lemma  says  that  simulation  is  preserved  by  NOAL  expressions 
if  it  is  preserved  by  each  recursively  defined  function. 

Lemma  6.2.1.  Let  A  be  a  set  of  typed  identifiers  and  function  identifiers.  Let  qi  G 
ENV {X ,  A)  and  r]2  €  ENV{X ,  B)  be  environments. 

If  71.  is  a  simulation  relation  between  A  and  B  for  NomSig  and  <  and  if  rji'Rr}2^  then 
for  all  types  T  and  for  all  recursion- free  NOAL  expressions  E  of  nominal  type  T  whose 
free  identifiers  and  function  identifiers  are  a  subset  of 

MlE}(A,q^)^l^  M{E]{B,q2). 

Proof:  (by  induction  on  the  structure  of  expressions). 

For  the  basis,  we  suppose  that  the  expression  is  either  an  identifier,  bottom  [T],  or 
the  invocation  of  a  nullary  generic  operation  symbol.  If  the  expression  is  an  identifier. 
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then  the  result  follows  from  rji'R.rji.  If  the  expression  is  bottom  [T]  for  some  type  T,  then 
the  result  follows  from  the  bistrictness  of  If  the  expression  is  g()  for  some  nullary 
generic  operation  symbol  g  of  nominal  signature  — >  T,  then  since  r)i'R.T]2,  by  definition 
of  a  homomorphic  relation  we  have 

For  the  inductive  step  we  assume  that  if  r)i  then  the  denotation  of  each  subex¬ 
pression  of  nominal  type  T  in  the  environment  tji  is  related  by  TZy  to  the  denotation  of 
the  same  subexpression  in  the  environment  There  are  several  C2ises  (see  Figures  3.1 
and  3.2). 

•  Suppose  the  expression  is  g(E)  and  E  is  not  empty.  Since  this  expression  has  a 

nominal  type,  by  the  type  inference  rules  it  must  be  that  S  — ♦  T  G  NomSig{g),  E 
h^ls  nominal  type  a,  cri  =  Si,  and  for  i  from  2  to  n,  <r,  <  S,-.  Let  q  6  M[E]{A,r}i) 
be  given.  By  the  inductive  hypothesis,  there  is  some  f  G  M[E]{B, t)2)  such  that 
q'lZg  f.  Since  <Ti  =  Si,  since  for  i  from  2  to  n,  o-,  <  Sj,  C 

Therefore  Ttg  Q  and  so  g  7?.g  r\  Let  z  :  S  be  a  list  of  typed  identifiers,  none  of 
which  occurs  free  in  E.  Since  qTl-^  r,  if  we  bind  9  to  z  in  (written  r]\\ql^)  and 
we  bind  f  to  z  in  7/2,  then  (»7i[4yz])'7^(»?2[r/z]).  Since  7?^  is  a  homomorphic  relation, 
it  follows  that 

A^[g(z)l(^^i[9/^)'^TMlg(z)l(5,J72[r/z]).  (6.10) 

Furthermore,  from  the  definition  of  NOAL  one  can  show  that 

M[g{E)]{A,qi)  =  U  ^Ig(z)l(^.^i[9/z])-  (6-11) 

Therefore,  for  every  possible  result  q  G  Mlg{E)}{A,qi)  there  is  some  r  G 
Af [g(£)](5, 7/2)  such  that  q'Rir. 

•  Suppose  the  expression  is  f{E)  and  f  is  a  function  identifier  of  nominal  signature 

S  — >  T.  Since  this  expression  has  a  nominal  type,  by  the  type  inference  rules  it 
must  be  that  E  has  nominal  type  a  and  a  <  S.  Let  q  G  M\E\{A,qi)  be  given. 
By  the  inductive  hypothesis,  there  is  some  r  G  M\E\{B^q2)  such  that  qllg  f. 
Since  <  S,  C  'JZg  and  so  qTZ^  r.  Since  771  TZ  772,  ^i(f)  ^2(f),  and 


thus  (j?2(f))(j^-  So,  by  definition  of  NOAL,  for  every  possible  result 

q  G  A1[f (^)l(A, T/i)  there  is  some  r  G  Ai[f{E)]{B,q2)  such  that  q'Rjr. 

Suppose  the  expression  is  (f  un(x  :  S)Eo){E)  and  that  the  nominal  type  of  the  entire 
expression  is  T.  Let  q  G  M[E]{A,qi)  be  given.  By  the  inductive  hypothesis,  there 
is  some  f  G  M\E\{B,  ^2)  such  that  q'Rgr,  where  a  is  the  nominal  type  of  E.  Since 
the  expression  has  a  nominal  type,  by  the  type  inference  rules  for  NOAL  it  must 
be  that  a  <  S;  thus  q'Rg  r.  It  follows  that  if  we  bind  g  to  x  in  qi  and  r  to  x  in 
7/2,  then  iqi[q/i^)  'R-  (7/2(77^);  thus  the  result  follows  by  the  inductive  hypothesis 
(applied  to  Eq). 

Suppose  the  expression  is  if  E\  then  E2  else  E3  fi.  Since  Bool  is  a  visible 
type  and  TZ  is  V-identical,  the  possible  results  from  Ex  in  t/j  are  a  subset  of  those 
possible  in  ^2-  Therefore  the  result  follows  from  the  inductive  hypothesis  applied 
to  E2  and  E3. 

Suppose  the  expression  is  Ex  (]  E2.  The  possible  results  of  this  expression  are  the 
union  of  those  from  Ex  and  E2.  Since  the  expression  has  a  nominal  type,  the  types 
of  both  Ex  and  E2  must  be  the  same,  say  T.  By  the  inductive  hypothesis,  for  every 
possible  result  q  of  Ex  in  the  environment  qx  there  is  some  possible  result  r  from  Ex 
in  the  environment  72  such  that  q  7Zj  r;  similarly  for  E2.  Hence  the  result  follows. 

Suppose  the  expression  is  Ex  V  ^2  and  has  type  T.  The  possible  results  of  this 
expression  are  the  union  of  those  from  Ex  and  E2,  except  that  ±  appears  only 
if  it  is  a  possible  result  of  both.  This  is  the  same  as  the  previous  case,  except 
that  we  have  to  be  careful  about  X.  Suppose,  for  the  sake  of  contradiction,  that 
there  was  some  q  in  M\Ex  V  ^2l(-d, 71)  such  that  q  is  not  related  by  TZr  to  some 
element  of  M\Ex  V  ^21(5,72).  By  the  previous  case,  if  M\Ex\}^2\[B ,^2)  is  the 
same  as  Ai\Ex  V  E2\{B,  72),  then  this  would  be  a  contradiction;  so  we  can  assume 
that  M\Ex  V  E2\{B,q2)  does  not  include  X  and  q  X.  Since  TZy  is  bistrict,  it 
must  be  that  7  =  X.  Furthermore,  by  definition  of  y?  since  M\Ex  V  E2\{B,q2) 
does  not  include  X,  it  must  be  that  either  Ex  or  E2  is  guaranteed  to  termi¬ 
nate  in  B  and  72.  Without  loss  of  generalit}',  suppose  X  ^  Ad[£i](B, 72). 
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Then  ±  ^  since  Ti.  is  bistrict  and  by  the  inductive  hypothesis 

M\E\\{A^r}\)  TZi  A^|£'i](5, 7/2).  But  then  by  definition  of  NOAL’s  angelic  choice 
operator,  J.  is  not  in  M\Ei  V  ■^2l(A, 771).  This  contradicts  the  assumption  that 
q  G  AilEi  V  £^2l(A,77i),  since  9  =  _L.  Hence  the  result  follows. 

•  If  the  expression  is  isDefTC^i),  then  the  i-esult  follows  directly  from  the  inductive 
hypothesis  applied  to  Ei  and  the  bistrictness  of  72.. 


The  proof  of  the  above  lemma  is  the  source  of  our  requirement  that  simulation  re¬ 
lationships  at  a  subtype  also  hold  at  each  supertype.  This  property  guarantees  that 
expressions  related  at  a  subtype  are  also  related  when  we  exploit  inclusion  polymor¬ 
phism.  For  example,  if  E  has  nominal  type  S,  S  is  a  subtype  of  T,  and  the  function 
identifier  f  has  nominal  signature  T  ^  U,  then  the  expression  f(.E)  is  type-safe;  further¬ 
more,  if  the  meanings  of  E  in  t)i  and  772  are  related  at  type  S  and  if  the  meanings  of  f 
are  also  related  at  type  T  — »  U,  then  by  this  property  the  arguments  are  related  at  the 
nominal  argument  type  T,  and  thus  the  results  are  related  at  the  nominal  result  type  U. 

6.2.2  The  Substitution  Property  for  NOAL  Programs 

To  show  that  the  substitution  property  holds  for  NOAL  programs  we  need  to  show  that 
simulation  is  preserved  by  recursively- defined  NOAL  functions.  The  proof  is  involved  be¬ 
cause  of  NOAL’s  erratic  and  angelic  choice  expressions  and  has  therefore  been  relegated 
to  Appendix  C.  However,  the  idea  of  the  proof  can  be  stated  as  follows.  To  deal  with 
functions  that  use  only  erratic  choice  one  uses  a  family  of  approximations,  each  of  which 
is  deterministic  and  that  together  cover  the  choices  available  to  functions  that  use  erratic 
choice.  To  deal  with  angelic  choice  one  first  rewrites  the  functions,  replacing  angelic  with 
erratic  choices  and  uses  the  limit  of  the  erratic  choice  approximations  as  a  first  approx¬ 
imation.  Then  one  expands  recursive  calls  in-line,  obtaining  a  series  of  approximations 
that  use  angelic  choice  for  deeper  and  deeper  recursions.  At  each  stage  of  approximation, 
simulation  is  preserved.  We  also  show  that  simulation  is  preserved  by  the  various  limit 
operators.  This  series  of  lemmas  culminates  in  the  following  result. 
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Lemma  6.2.2.  Let 

fun  fi(x*,  :  S*i)  ;  T,  =  £i; 

fm(Xm  •  i  Tjn  =  Em 

be  a  mutually  recursive  system  of  NOAL  function  definitions. 

Suppose  7^  is  a  simulation  relation  between  algebras  A  and  B  for  NomSig  and  <. 
Then  for  each  j  from  1  to  m, 

nA)[fj]ns~^r,nB){tj].  (6.12) 

Proof;  See  Appendix  C.  ■ 

Using  the  above  lemma,  we  can  prove  that  simulation  is  a  valid  criterion  for  imitation. 

Theorem  6.2.3.  Let  E  be  a  signature.  Let  A  and  B  be  S-algebras.  Let  NomSig  be  a 
nominal  signature  map.  Let  <  be  a  binary  relation  on  type  symbols. 

Suppose  that  72.  is  a  simulation  relation  between  A  and  B  for  NomSig  and  <.  Then 
for  all  sets  of  typed  identifiers  X,  for  all  environments  E  ENV(X,A),  and  for  all 
environments  j/b  €  ENV(X ,  B),  if  then  {A^tja)  imitates  {B,TjB)  with  respect 

to  the  set  of  all  type-safe  NOAL  programs  over  NomSig  and  <. 

Proof:  Suppose  that  72  is  a  simulation  relation  between  A  and  B  for  NomSig  and 
<.  Let  X  be  a  set  of  typed  identifiers  and  let  rji  G  ENV{X ,A)  and  772  €  ENV{X,  B)  be 
such  that  771  72  772.  Let  P  be  a  type-safe  NOAL  program  over  NomSig  and  <.  In  general 
P  has  the  form 

fun  fi(zl  :  Si)  :  Tj  =  Ei; 

^m(^m  •  Sto)  •  Tjn  =  Emj 

E. 

Since  P  is  type-safe,  P  has  some  nominal  type,  say  T.  Let  Z  be  the  set  of  typed  function 
identifiers  that  contains  the  fj  with  their  nominal  signatures.  Let  77J  €  ENV{Z  U  X,A) 
and  772  €  ENV{Z  U  X,B)  be  defined  so  that  for  all  x  G  A,  77i(x)  =  r]i{x),  rj^ix)  =  772(x) 
and  for  all  fj  G  Z,  ‘rj[{fj)  is  the  denotation  of  fj  in  A  and  »72(f>)  is  the  denotation  of  fj 
in  B.  By  Lemma  6.2.2,  77J  since  the  denotations  of  recursively  defined  functions  are 
related  by  72.  So  by  Lemma  6.2.1, 


MlEl{A,ri[)nj  M[E]{B,ti',). 


(6.13) 
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Therefore,  by  the  semantics  of  NOAL  programs, 

MlPj{A,  rji)  TItMIPUB,  m).  (6.14) 

Recall  that  this  means  that  for  each  q  6  A4fP](A, 7;i),  there  is  some  r  G  A4[P]{B,t]2) 
such  that  q  IZj  r.  Since  P  is  a  program,  its  nominal  type  must  be  a  visible  type;  that  is, 
T  6  R.  Since  IZ  is  V-identical,  for  each  q  6  A4[P|(A,7;i),  there  is  some  r  6  Ad[P](J3, 772) 
such  that  q  =  r;  that  is, 

MlP]iA,rj,)  C  M{Pj{B,q2).  (6.15) 

Therefore  (A^tji)  imitates  (B,r}2)  with  respect  to  the  set  of  type-safe  NOAL  programs 
over  NomSig  and  <.  So  by  definition,  TZ  is  an  imitation  relation.  I 

The  significance  of  the  above  theorem  is  that  simulation  relations  can  be  used  to  prove 
that  a  binary  relation  on  types  is  a  subtype  relation  with  respect  to  the  set  of  type-safe 
NOAL  programs,  as  discussed  in  the  next  section. 

6.3  Proving  Subtype  Relations  using  Simulation  Relations 

In  this  section  we  describe  our  technique  of  proving  subtype  relations  using  a  simulation 
relation. 

The  idea  is  to  find  simulation  relations  that  witness  a  subtype  relation  in  the  sense 
that  they  relate  every  instance  of  a  subtype  to  some  instance  of  its  supertypes. 

Definition  6.3.1  (witnesses).  Let  S  be  a  signature.  Let  C  and  A  be  S-algebras.  Let 

<  be  a  binary  relation  on  types.  A  typed  family  of  relations  TZ  between  C  and  A  witnesses 

<  if  and  only  if  for  all  types  S  and  T, 

(S  <  T)  =>  (Cs  7Zt  At).  (6.16) 

To  prove  that  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  type-safe 
NOAL  programs,  one  must  find  simulation  relations  that  witness  <  for  each  SPEC- 
algebra. 

Theorem  6.3.2.  Let  E  be  a  signature.  Let  SPEC  be  a  set  of  E-algebras.  Let  NomSig 
be  a  nominal  signature  map.  Let  <  be  a  binary  relation  on  types. 
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If  for  every  C  €  SPEC  there  is  some  A  E  SPEC  and  some  simulation  relation  'Jt 
between  C  and  A  for  NomSig  and  <  such  that  TZ  witnesses  <,  then  <  is  a  subtype 
relation  on  the  types  of  SPEC  with  respect  to  the  set  of  type-safe  NOAL  programs  over 
NomSig  and  <. 

Proof:  Let  C  E  SPEC  be  given.  By  hypothesis,  there  is  some  A  E  SPEC  and  some 
simulation  relation  between  C  and  A  for  NorriSig  and  <  such  that  TZ  witnesses  <.  Let 
A'’  be  a  set  of  typed  identifiers.  Let  r)c  €  ENV{X ,C)  be  such  that  tjc  obeys  <. 

Since  TZ  witnesses  <  we  can  build  a  nominal  environment  gA  E  ENV {X ,  A)  such  that 
Vc  E'l A-  That  is,  for  each  x  :  T  6  A'',  there  is  some  type  S  <  T  such  that  t/c(x)  G  C's- 
Since  7Z  witnesses  <,  there  is  some  r  E  Aj  such  that  ^  So  let  rjAi*)  *= 

Since  T)c  P-  Va,  by  Theorem  6.2.3,  {C,t]c)  imitates  {A,t)a)  with  respect  to  the  set  of 
type-safe  NOAL  programs  over  NomSig  and  <.  So  by  definition,  <  is  a  subtype  relation. 
I 

The  above  technique  for  proving  subtype  relations  may  not  be  complete.  That  is, 
although  finding  simulation  relations  that  witness  <  is  sufficient  to  prove  that  <  is  a 
subtype  relation,  we  do  not  know  whether  this  condition  is  necessary  for  <  to  be  a 
subtype  relation.  A  simpler  problem,  which,  if  it  can  be  answered  in  the  affirmative, 
would  imply  the  completeness  of  our  technique  for  proving  subtype  relations,  is  the 
following:  if  (C,  r/c)  imitates  {A,t]a)  with  respect  to  the  set  of  type-safe  NOAL  programs 
over  NomSig  and  <,  is  there  a  simulation  relation  TZ  between  C  and  A  for  NomSig  and 
<  such  that  tjcTZva^  However,  this  simpler  problem  is  not  equivalent  to  the  problem  of 
whether  our  technique  for  proving  subtype  relations  is  complete. 

In  the  rest  of  this  section  we  look  at  some  ways  to  make  our  proof  technique  more 
practical. 

6.3.1  Modularity  in  Proofs  of  Subtype  Relations 

In  this  subsection  we  discuss  the  problem  of  proving  subtype  relationships  instead  of 
subtype  relation... 

Our  formal  treatment  of  subtyping  deals  with  subtype  relations  instead  of  subtype 
relationships.  .So  formally,  we  cannot  prove  that  one  type  is  a  subtype  of  another,  but 
only  that  a  particular  binary  relation  on  types  is  a  subtype  relation.  This  is  less  modular 
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than  one  would  like,  because  it  recjuires  one  to  look  at  all  the  types  in  a  program  at  once 
instead  of  looking  at  individual  subtype  relationships. 

To  attack  the  modularity  problem  directly  one  would  have  to  find  conditions  on  type 
specifications  and  the  set  of  observations  that  would  allow  individual  subtype  relation¬ 
ships  to  be  checked.  Another  way  to  attack  this  problem  would  be  to  consider  adding 
types  one  at  a  time  to  a  specification  and  to  consider  the  question  of  what  conditions  on 
the  new  type  specification  will  ensure  that  a  subtype  relation  on  the  old  type  specification 
is  still  a  subtype  relation  on  the  new  type  specification.  We  leave  these  approaches  as 
problems  for  future  work. 

One  reason  for  leaving  this  problem  for  future  work  is  the  difficulty  of  giving  a  general 
definition  of  subtype  relationships  instead  of  subtype  relations.  One  way  to  define  subtype 
relationships  would  be  to  show  that  for  each  specification  there  is  a  largest  subtype 
relation,  and  then  to  say  that  S  is  a  subtype  of  T  if  they  are  related  by  this  largest 
relation.  The  binary  relations  on  a  set  of  type  symbols  can  be  partially  ordered  by  set 
inclusion  (C).  If  <iC<2,  then  we  say  that  <2  is  larger  than  <\.  So  <  is  the  largest 
subtype  relation  on  the  types  of  a  specification  if  it  is  larger  than  all  other  subtype 
relations  on  that  specification’s  types.  However,  we  will  show  by  an  example  below  that 
with  respect  to  an  arbitrary  set  of  observations  there  may  be  no  largest  subtype  relation 
for  a  given  specification. 

Another  problem  with  largest  subtype  relations  is  that  the  set  of  observations  defined 
by  type-safe  programs  changes  when  the  presumed  subtype  relation  changes.  For  exam¬ 
ple,  the  set  of  type-safe  NOAL  programs  is  determined,  in  part,  by  the  presumed  subtype 
relation.  The  same  is  true  in  Trellis/Owl.  We  do  not  know  whether  there  are  example 
specifications  where  there  are  two  incomparable  binary  relations  on  types  such  that  each 
is  a  subtype  relation  with  respect  to  the  corresponding  set  of  type-safe  programs. 

On  the  other  hand,  the  lack  of  a  largest  subtype  relation  is  not  terribly  important 
to  programmers.  One  normally  writes  a  type  specification  with  some  subtype  relation 
in  mind,  since  one  has  to  choose  the  names  of  instance  operations  and  specifications 
carefully  to  make  the  desired  subtype  relationships  hold.  So  programmers  should  be 
more  interested  in  whether  a  particular  binary  relation  on  types  is  a  subtype  relation 
than  in  finding  all  the  subtype  relations  for  a  given  specification. 
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In  the  rest  of  this  section  we  present  an  example  with  two  incomparable  subtype 
relations  and  no  subtype  relation  that  is  larger  than  both.  Our  example  involves  two 
types,  T1  and  T2.  Since  our  specification  language  cannot  handle  this  example,  consider 
the  algebra  A  presented  in  Figure  6.1  as  the  only  algebra  in  the  semantics  of  a  specification 
we  will  call  T12. 

Let  <1  be  the  smallest  reflexive  relation  on  the  types  of  T12  such  that  T1  <i  T2. 
Let  <2  be  the  smallest  reflexive  relation  on  the  types  of  T12  such  that  T2  <2  Tl.  We 
claim  that  <1  and  <2  are  subtype  relations  on  the  types  of  T12  with  respect  to  the  set 
of  observations  OBS  described  by  the  NOAL  program  g(x2,  xl),  where  xl  :  Tl  and 
x2  :  T2. 

Lemma  6.3.3.  Let  <1  «ind  OBS  be  as  described  above.  Then  the  relation  <1  is  a 
subtype  relation  on  the  types  of  T12  with  respect  to  OBS. 

Proof:  Let  A  be  a  set  of  typed  identifiers,  indexed  by  the  types  of  T12.  Let  tja  € 
ENV{X,A)  be  an  environment  that  obeys  <1.  If  {xl  :  Tl,x2  :  T2}  2  then  by 
definition,  {A,'r]A)  imitates  (A,Tf)  with  respect  to  OBS.,  for  all  nominal  environments 
T]  €  ENV(X ,  A).  If  (xl  :  Tl,x2  :  T2}  C  X,  then  let  t)2  €  ENV(X,A)  be  defined  so  that 
for  all  X  :  Tl  €  A,  t/2(x)  ^  a,  for  all  x  :  T2  €  A,  r;2(x)  *=  6,  and  for  all  other  identifiers, 
7/2(x)  =  Note  that  772  is  a  nominal  environment.  The  only  observation  in  OBS  is 

the  program  above.  Note  that 

A^[g(x2,xl)J(A,?7A)  =  {false}  (6.17) 

Af[g(x2,xl)|(A,J72)  =  [false].  (6.18) 

The  first  equation  holds  because  the  generic  invocation  mechanism  either  calls  giaji—Booi 
or  gTi.Ti— Bool-  Therefore,  (A, 77^1)  imitates  (A, 772)  with  respect  to  OBS.  Since  for  all 
environments  77^  this  construction  produces  a  nominal  algebra-environment  pair  (A,  772), 
by  definition  <  is  a  subtype  relation.  I 

Lemma  6.3.4.  Let  <2  and  OBS  be  as  described  above.  Then  the  relation  <2  is  a 
subtype  relation  on  the  types  of  T12  with  respect  to  OBS. 

Proof:  Let  rjA  G  ENV{X,A)  be  an  environment  that  obeys  <2.  If  (xl  ;  Tl,x2  : 
T2}  C  A,  then  we  can  define  a  nominal  environment  772  G  ENV[X ,  A)  as  in  the  previous 


Figure  6.1;  The  Tl2-algebra,  A. 
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proof.  Again 

A4(g(x2,xl)l(A,»/^)  =  {false}  (6.19) 

A4(g(x2,xl)KA,J?2)  =  {false),  (6.20) 

where  the  first  equation  holds  because  the  generic  invocation  mechanisnr  either  calls 
gT2,Tl-.Bool  or  gT2,T2-.Bool-  ■ 

However,  the  union  <i  and  <2  is  not  a  subtype  relation  with  respect  to  OBS.  To  see 
this,  let  X  =  {xl  :  Tl,x2  :  T2},  and  consider  the  environment  7/3  G  ENV {X ,  A)  defined 
such  that  J?3(xl)  *=  b  and  773(x2)  a.  Then  obeys  <1  U  <2,  but 

Mlg{x2,xl)]{C,rf3)  =  {true},  (6.21) 

although  this  cannot  happen  in  a  nominal  environment. 

As  we  show  in  the  following  lemma,  there  can  be  no  subtype  relation  that  contains 
<1  U  <2,  since  every  subset  of  a  subtype  relation  is  also  a  subtype  relation. 

Lemma  6.3.5.  Let  S  be  a  signature  and  let  SPEC  be  a  nonempty  set  of  S-algebras. 
Let  OBS  be  a  set  of  observations.  Let  <  be  a  binary  relation  on  types. 

If  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  OBS,  then  every 
subset  of  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect  to  OBS. 

Proof:  Suppose  <'  is  a  subset  of  <•  Let  C  G  SPEC  be  given.  Let  A  be  a  set 
of  typed  identifiers,  and  let  rjc  €  ENV{X,C)  be  such  that  rjc  obeys  <'.  Since  <'C<, 
T]c  obeys  <.  So  by  definition  of  subtype  relation,  there  is  some  A  G  SPEC  and  some 
nominal  environment  G  ENV{X,A)  such  that  (C,r}c)  imitates  (A,  7/4)  with  respect  to 
OBS.  Since  the  same  algebra  A  can  be  used  for  all  environments  over  C,  <'  is  a  subtype 
relation.  I 

Therefore  there  is  no  largest  subtype  relation  on  the  types  of  T12  with  respect  to  the 
set  of  observations  described  by  the  NOAL  program  g(xl,x2). 

One  might  object  that  the  set  of  observations  for  the  above  example  is  so  small.  For 
example,  if  the  program  g(xl,x2)  were  included  in  the  set  of  observations,  then  neither 
<1  nor  <2  would  be  a  subtype  relation  with  respect  to  this  enlarged  set  of  observations. 
We  leave  it  as  an  open  problem  whether  there  is  some  set  of  conditions  on  specifications 
and  observations  that  ensures  that  there  are  largest  subtype  relations. 
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In  general  there  may  not  be  a  largest  simulation  relation  between  two  algebras  for 
a  given  nominal  signature  map  and  presumed  subtype  relation.  We  could  show  this  by 
adapting  one  of  Nipkow’s  examples  that  has  two  incomparable  simulation  relations  whose 
union  is  not  a  simulation  relation  [Nip87,  Page  52]. 

6.3.2  Using  Universal  Models  in  Proving  Subtype  Relations 

If  one  wants  to  prove  that  a  binary  relation  is  a  subtype  relation,  it  would  be  convenient 
to  just  w'ork  with  the  abstract  values  of  types  [Hoa72]  instead  of  all  algebraic  models. 
Many  specifications  have  algebraic  models  whose  carrier  sets  can  be  thought  of  as  the 
set  of  abstract  values  of  the  corresponding  types.  Such  specifications  are  said  to  have 
universal  models. 

Intuitively,  a  universal  model  of  a  type  specification  is  maximally  nondeterministic 
and  therefore  exhibits  all  the  behavior  allowed  by  that  specification.  That  is,  all  models 
of  the  specification  are  implementations  of  the  universal  model  [Hes88].  Because  of  this 
property,  a  universal  model  of  a  specification,  if  it  exists,  is  also  as  “abstract”  as  possible. 
Therefore,  if  a  specification  has  a  universal  model  we  can  identify  the  carrier  set  of  each 
type  in  the  universal  model  with  the  abstract  values  of  each  type.  Furthermore,  we  will 
show  that  if  we  have  a  simulation  relation  between  a  universal  model  and  itself  that 
witnesses  <  then  we  can  conclude  that  <  is  a  subtype  relation. 

Instead  of  defining  universal  models  using  sorted  homomorphisms  on  algebras,  the 
following  definition  uses  the  imitates  relation,  which  is  more  convenient  for  us.  However, 
since  sorted  homomorphisms  do  not  map  objects  of  one  type  to  objects  of  another  type, 
the  following  definition  does  require  that  every  environment  imitates  some  environment 
of  the  universal  model  where  each  identifier  is  mapped  to  an  object  of  the  same  type. 

Definition  6.3.6  (universal  model).  Let  E  be  a  signature  and  let  SPEC  be  a  set  of 
E-algebras.  Let  OBS  be  a  set  of  observctions.  Then  /4  is  a  universal  model  of  SPEC 
with  respect  to  OBS  if  and  only  if  for  every  algebra  C  €  SPEC,  for  all  sets  of  typed 
identifiers  X,  and  for  all  environments  rjc  G  ENV{X ,C),  there  is  some  environment 
rjA  e  ENV{X ,A)  such  that  {C,t}c)  imitates  {A,t}a)  with  respect  to  OBS  and  for  all 
identifiers  x  G  .V,  774  (x)  h^ls  the  same  type  as  r}c{x). 
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We  say  that  an  algebra  is  a  universal  model  of  a  specification  SPEC  with  respect  to  some 
set  of  observations  if  it  is  a  universal  model  of  the  set  of  ^PFC-algebras  with  respect  to 
that  set  of  observations. 

For  example,  a  maximally  nondeterministic  Mob-algebra  is  a  universal  model  of  the 
specification  Mob  with  respect  to  the  set  of  observations  that  contains  the  single  NOAL 
program  next(x),  where  x  has  nominal  type  Mob.  To  see  this,  suppose  A  is  a  maxi¬ 
mally  nondeterministic  Mob-algebra  whose  carrier  set  for  Mob  is  J.  plus  all  finite  sets  of 
integers.  Let  C  be  a  Mob-algebra.  Let  rje  G  ENV{{x  ;  Mob}, (7)  be  such  that  the  set  of 
integers  waiting  in  7/c(x)  is  some  set  R.  (That  is,  for  all  integers  i,  i  G  R  if  and  only 
if  Ad[waiting?(x,  i)J(C',  J/c-fi/ij)  =  {true}.)  Let  6  ENV{{x  :  Mob),  A)  be  such  that 
=  R.  Then  by  the  specification  of  Mob, 

7Vf[next(x)](C,T/c)  Q  R  =  AdInext(x)J(A,  t/^).  (6.22) 

So  (C,  r)c)  imitates  (A,  t)a)  with  respect  to  this  set  of  observations  and  thus  A  is  universal. 

Unfortunately,  not  every  specification  has  a  universal  model.  For  example,  the  spec¬ 
ification  of  the  type  Crowd  given  in  Figure  5.1  has  no  universal  model  with  respect  to 
type-safe  NOAL  programs.  The  reason  is  that  different  Crowd-algebras  may  have  different 
algorithms  for  their  next  operation,  and  since  the  next  operation  must  be  deterministic, 
there  is  no  single  Crowd-algebra  that  captures  all  this  behavior.  Notice  that  the  abstract 
values  of  the  type  Crowd  do  not  fully  describe  the  behavior  of  Crowd  objects,  since  from 
the  abstract  value  one  cannot  tell  what  waiting  integer  will  be  chosen  by  next,  unlike 
the  abstract  values  of  type  PSchd. 

When  a  specification  has  a  universal  model,  however,  it  eases  the  problem  of  finding 
subtype  relations,  2is  the  following  lemma  shows. 

Lemma  6.3.7.  Let  E  be  a  signature  and  let  SPEC  be  a  nonempty  set  of  E-algebras. 
Let  OBS  be  a  set  of  observations.  Let  <  be  a  binary  relation  on  type  symbols. 

Suppose  A  is  a  universal  model  of  SPEC  with  respect  to  OBS.  Then  <  is  a  subtype 
relation  on  the  types  of  SPEC  with  respect  to  OBS  if  and  only  if  for  all  sets  of  typed 
identifiers  X  and  for  all  environments  rjx  €  ENV{X,A)  such  that  t/i  obeys  <,  there 
is  some  nominal  environment  r/j  ^  ENV(X,A)  such  that  (A^rji)  imitates  (A, 72)  with 
respect  to  OBS. 
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Proof:  Let  A  be  a  universal  model  of  SPEC.  Suppose  that  for  all  sets  of  typed  iden¬ 
tifiers  A'  and  for  all  environments  rji  €  ENV{X,A)  such  that  rji  obeys  <,  there  is  some 
nominal  environment  Tf2  €  ENV (X ,  A)  such  that  {A,t)i)  imitates  {A,  7)2)  with  respect  to 
OBS.  Let  C  G  SPEC  be  an  algebra  and  let  rjc  €  ENV{X,C)  be  an  environment  that 
obeys  <. 

Since  /I  is  a  universal  model  of  SPEC,  there  is  some  environment  rji  G  ENV{X,A) 
that  obeys  <  and  such  that  {C,r]c)  imitates  {A, rji)  with  respect  to  OBS.  Since  rji 
obeys  <,  by  hypothesis  there  is  a  nominal  environment  772  6  ENV{X ,A)  such  that 
{A,t]i)  imitates  (A,  772)  with  respect  to  OBS.  By  Lemma  4.2.2,  the  imitates  relation  with 
respect  to  OBS  is  transitive.  Therefore  {C,t)c)  imitates  (A,  772)  with  respect  to  OBS.  So 
by  definition  <  is  a  subtype  relation. 

Conversely,  suppose  that  <  is  a  subtype  relation  on  the  types  of  SPEC  with  respect 
to  OBS.  Let  A  be  a  set  of  typed  identifiers.  Let  771  G  ENV{X,A)  be  an  environment 
that  obeys  <.  Since  <  is  a  subtype  relation,  there  is  some  B  G  SPEC  and  some  nominal 
environment  rjs  e  ENV {X ,  B)  such  that  (A,  771)  imitates  {B,t)b)  with  respect  to  OBS. 
Since  A  is  universal,  there  is  some  nominal  environment  772  G  ENV{X,A)  such  that 
(jB,77b)  imitates  (A, 772)  with  respect  to  OBS.  Since  the  imitates  relation  with  respect  to 
OBS  is  transitive,  (A,  771)  imitates  (A,  772)  with  respect  to  OBS.  ■ 

As  a  corollary  to  the  above  lemma,  if  we  have  a  universal  model  of  a  specification, 
we  only  need  to  find  a  simulation  relation  between  the  universal  model  and  itself  that 
witnesses  a  binary  relation  <  to  prove  that  <  is  a  subtype  relation. 

Corollary  6.3.8.  Let  SPEC  be  a  set  of  E-algebras.  Let  NomSig  be  a  nominal  signature 
map.  Let  <  be  a  binary  relation  on  type  symbols. 

If  A  is  a  universal  model  of  SPEC  and  if  there  is  a  simulation  relation  P.  between  A 
and  itself  for  NomSig  and  <  such  that  71  witnesses  <,  then  <  is  a  subtype  relation  on 
the  types  of  SPEC  with  respect  to  the  set  of  type-safe  NOAL  programs  over  NomSig 
and  <. 

Proof:  Suppose  that  A  is  a  universal  model  of  SPEC  and  that  there  is  a  simula¬ 
tion  relation  7Z  between  A  and  itself  that  witnesses  <.  Let  771  G  ENV{X ,A)  be  an 
environment  that  obeys  <.  Since  %  witnesses  <,  one  can  build  a  nominal  environment 
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J?2  €  ENV{X ,  A)  such  that  rji  'R.t)2.  By  Theorem  6.2.3,  {A,t]i)  imitates  {A,r]2).  Since  A 
is  a  universal  model  of  SPEC,  it  follows  by  Lemma  6.3.7  that  <  is  a  subtype  relation.  I 
As  an  example  of  proving  that  a  binary  relation  is  a  subtype  relation  on  the  types 
of  a  specification  with  a  universal  model,  consider  the  specification  IPT,  with  types 
IntPair  and  IntTriple.  Let  NomSig  be  the  nominal  signature  map  of  IPT  and  let 
<  be  smallest  binary  relation  on  the  types  of  IPT  such  that  IntTriple  <  IntPair. 
The  algebra  A  given  in  Figure  2.5  is  a  universal  model  of  IPT.  Let  TZ  be  the  smallest 
typed  family  of  relations  such  that  for  all  types  T,  if  </  6  At,  then  q  TZy  q,  and  for  all 
(91592593),  (91, 92,94)  G  Aintlriple  and  (91,^2)  G  AintPair, 


(91,92,93) 

^IntPair 

(91,92) 

(6.23) 

(91,92) 

"^IntPair 

(91,92,93) 

(6.24) 

(91,92,93) 

"^IntPair 

(91,92,94)- 

(6.25) 

We  showed  earlier  in  this  chapter  that  7^  is  a  simulation  relation.  We  now  note  that 
7Z  witnesses  <  because  every  proper  instance  of  IntTriple  is  related  to  an  instance  of 
IntPair  with  the  same  first  and  second  components.  Since  A  is  a  universal  model  of 
IPT,  it  follows  by  Corollary  6.3.8  that  <  is  a  subtype  relation  on  the  types  of  IPT  with 
respect  to  the  set  of  all  type-safe  NOAL  programs  over  NomSig  and  <. 

6.4  Examples  Proofs  of  Subtype  Relations 

In  the  following  subsections  we  prove  several  examples  of  subtype  relations  with  respect 
to  type-safe  NOAL  programs.  All  the  examples  were  introduced  earlier  chapters,  where 
much  smaller  sets  of  observations  were  used. 

6.4.1  Schedulers 

In  Chapter  5  we  discussed  the  specification  MCP,  with  three  types  of  schedulers:  Mob, 
Crowd,  and  PSchd  (see  Figure  2.6  on  page  39,  Figure  5.1  on  page  81,  and  Figure  4.2  on 
page  63).  The  specification  MCP  is  interesting  because  it  involves  a  nondeterministic 
type.  Mob,  and  two  incompletely  specified  types:  Mob  and  Crowd.  Furthermore,  MCP 
does  not  have  a  universal  model. 
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Let  <  be  the  smallest  reflexive  relation  on  the  types  of  MCP  such  that  Crowd  <  Mob 
and  PSchd  <  Mob.  (The  relation  <  is  depicted  in  Figure  5.2  on  page  82.)  In  Chapter  5 
we  argued  that  <  is  a  subtype  relation  on  the  types  of  MCP  with  respect  to  a  set  of  three 
NOAL  programs.  The  following  lemma  shows  that  <  is  a  subtype  relation  with  respect 
to  all  type-safe  NOAL  programs  over  the  nominal  signature  map  of  MCP  and  <. 

Lemma  6.4.1.  The  relation  <  described  above  is  a  subtype  relation  with  respect  to  all 
type-safe  NOAL  programs  over  the  nominal  signature  map  of  MCP  and  <. 

Proof:  Let  C  be  a  MCP-algebra.  Although  there  is  no  universal  model  of  MCP,  there 
is  an  algebra,  call  it  A,  with  the  same  carrier  set,  abstract  functions,  and  operations  as 
C,  except  that  the  operation  is  maximally  nondeterministic.  This  algebra 

A  is  a  MCP-algebra,  because  the  specification  of  Mob  permits  the  nextMob-»int  operation 
to  be  nondeterministic. 

Let  us  say  that  an  integer  i  is  waiting  in  a  scheduler  if  the  result  of  the  generic  invo¬ 
cation  waiting?(x, i)  in  an  environment  where  x  denotes  the  scheduler  and  i  denotes 
the  integer  i  is  true.  Then  we  can  define  a  homomorphic  relation  72.  between  C  and  A  for 
the  nominal  signature  map  of  MCP  and  <  as  follows.  Let  72  be  the  smallest  typed  family 
of  relations  between  C  and  A,  such  that  for  all  types  T,  72t  is  the  identity  on  Cj  (which 
is  the  same  as  At),  every  proper  instance  of  Crowd  or  PSchd  is  related  to  an  instance  of 
Mob  with  the  same  set  of  waiting  integers  by  72Mob  and  in  addition: 

“^Crowd  Q  72Hob  (6.26) 

"^PSchd  Q  '^Mob-  (6.27) 

By  this  construction  relationships  at  types  Crowd  and  PSchd  hold  at  type  Mob  and  72 
witnesses  <. 

We  now  show  that  72  is  a  homomorphic  relation.  Let  and  environments  t/i  6 
ENV {X ,  C)  and  772  G  ENV{X ,  A)  be  such  that  tji  72  rj2.  Suppose  g(x)  is  a  generic  invo¬ 
cation  of  some  nominal  type  T.  If  none  of  the  identifiers  in  x  have  nominal  type  Mob,  then 
by  construction  =  T]2{i)  and  thus  A1|g(x)J(C,  771)  =  A4[g(x)](A, 772).  Since  each  72t 
contains  the  identity  relation  on  Aj,  it  follows  that  A4lg(x)](C,  771)  72t  A4[g(x)](A,  772). 
So  it  remains  to  deal  with  generic  invocations  whose  arguments  have  nominal  type  Mob. 
In  the  following  cases,  suppose  that  x  :  Mob  6  X  and  i  ;  Int  €  X . 


Suppose  the  generic  invocation  is  ins(x,i).  Let  q  be  the  only  possible  result  of 
A^[ins(x,  7;i)  and  let  r  be  the  only  possible  result  of  At[ins(x,  i)J(A, r;2). 

Since  j;i(x)  7?Mob  ^2(2^),  both  J/i(x)  and  have  the  same  set  of  waiting  integers, 

call  it  s.  By  the  specification  of  ins  in  the  three  scheduler  types,  the  set  of  waiting 
integers  for  <7  is  s  U  {?},  where  i  is  77i(i).  Since  77i(i)  T^int  J?2(i)  and  TZint  is  the 
identity,  the  set  of  waiting  integers  for  r  is  also  s  U  {i}.  So  by  definition  of  T^Mob) 
q  "^Mob  r. 

Suppose  the  generic  invocation  is  waiting? (x,i).  Since  ^Mob  J?2(x),  both 
77i(x)  and  »?2(*)  have  the  same  set  of  waiting  integers.  As  above,  the  denotation  of 
i  must  be  the  same  in  both  environments.  So  by  definition  of  “waiting  integer,” 
the  denotation  of  waiting?(x, i)  must  be  the  same  in  both  environments.  Since 
T^BooI  is  the  identity  on  the  carrier  set  of  Bool,  we  have 

M fwait  ing?(x,  i )I (C,  )  T^booi  >1  [wait  ing?(x,  i )] ( A,  772 ) . 

Suppose  the  generic  invocation  is  empty?(x).  As  above,  both  771  (x)  and  ti2[x)  have 
the  same  set  of  waiting  integers.  So  by  the  specification  of  the  empty?  operations  of 
the  various  types,  the  denotation  of  empty?  (x)  is  the  same  in  both  environments. 

Suppose  the  generic  invocation  is  next(x).  Since  771  (x)  T^Mob  ^2(x),  both  771  (x)  and 
772(x)  have  the  same  set  of  waiting  integers,  call  it  3.  By  definition  of  7?.,  either 
772(x)  denotes  an  instance  of  Mob,  or  77i(x)  =  772{x)  if  772(x)  denotes  an  instance  of 
PSchd  or  Crowd.  In  the  latter  case,  the  result  is  trivial,  so  suppose  772 (x)  denotes 
an  instance  of  Mob.  Recall  that  the  algebra  A  is  defined  so  that 

Ad[next(x)J(A,  772)  =  s  (6.28) 

because  the  operation  ^next^ob-int  Jnaximally  nondeterministic.  By  the  specifi¬ 
cations  of  the  three  types,  the  set  of  possible  results  for  Af  [next(x)](C,  77,)  must 
be  a  subset  of  s.  Therefore, 

Ad[next(x)](C,  771)  C  Ad[next(x)J(A,  772).  (6.29) 

Since  "Rint  is  the  identity  relation  on  the  carrier  set  of  Int,  it  follows  that 
Ad[next(x)J(6’, 771)  T^int  Ad[next(x)j(/4, 72),  since  this  means  that  for  each  q  G 
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yVf[next(x)](C,  r/i),  there  is  some  r  €  A4[next(x)J(/l,  7/2)  such  that  ^  =  r,  or  in 
other  words  that  Al{next(x)](C', j;i)  C  AfInext(x)](A, 7;2)- 

So  this  72.  is  a  homomorphic  relation.  By  construction  72  is  also  V-identical  and  bistrict; 
hence  72  is  a  simulation  relation.  Since  72  witnesses  <,  the  result  follows  by  Theo¬ 
rem  6.3.2.  I 

6.4.2  OneOfs 

In  this  subsection  we  will  show  how  the  general  subtyping  rule  given  by  Cardelli  for  his 
immutable  variant  types  [Car84]  holds  for  our  OneOf  types.  This  example  shows  that 
our  definition  of  subtype  relations  encompasses  Cardelli’s  rule  for  OneOf  types.  That  is, 
a  OneOf  type  with  fewer  tags  is  a  subtype  of  a  OneOf  type  with  more  tags,  provided  each 
type  associated  with  a  tag  in  the  first  OneOf  type  is  a  subtype  of  the  corresponding  type 
in  the  second  OneOf  type. 

We  discussed  OneOf  types  in  Chapters  2  and  4,  where  they  are  used  to  model  ex¬ 
ceptions.  We  now  introduce  a  slightly  more  general  specification  of  OneOf  types,  which 
properly  treats  tags  whose  associated  types  may  have  supertypes.  A  representative  OneOf 
type  specification  is  given  in  Figure  6.2,  where  the  type  is  abbreviated  to  012.  In  a  OneOf 
type  name,  the  order  of  the  tag  declarations  (ni:Si)  does  not  matter.  The  trait  that 
specifies  the  carrier  set  and  abstract  functions  of  OneOf  types  is  given  in  Figure  2.7  on 
page  40.  Note  that  the  value  [T]  operations  are  defined  for  all  types  T\  their  specification 
uses  the  presumed  subtype  relation  <  that  we  will  define  below  in  this  example. 

Let  S  be  a  specification.  The  specification  S  describes  the  data  found  in  the  simplest 
OneOf  types  and  is  a  bcisis  for  the  inductive  construction  that  follows.  Let  <s  be  a 
reflexive  subtype  relation  on  the  types  of  S  with  respect  to  type-safe  NOAL  programs 
over  the  nominal  signature  map  of  S  and  <$•  We  assume  that,  for  every  S-algebra  C, 
there  is  some  S-algebra  A  and  a  simulation  relation  between  C  and  A  for  the  nominal 
signature  map  of  S  and  <5  such  that  the  simulation  relation  witnesses  <5. 

Let  O  be  a  specification  that  includes  S  and  several  OneOf  types  of  the  form 
OneOf  [nl :  SI , . . .  ,nk :  Sk] ,  where  the  Si  are  either  types  from  the  specification  S  or  other 
OneOf  types  of  this  form.  (So  that  all  the  algebras  that  satisfy  the  specification  0  are 
flat,  as  required  for  NOAL  programs  in  Appendix  C,  we  require  that  if  an  Si  is  a  type 
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Figure  6.2:  Specification  of  the  type  012  =  0ne0f[ni  :  Si,n2  :  Sj]. 

012  immutable  type 

class  ops  [mcike_ni,  make_n2] 

instance  ops  [hasTag?,  value[T]] 
based  on  sort  OneOf  from  OneOf[nj  :  Si,n2  :  S2] 

op  make_ni(c;0l2Class,  x:  Si)  returns(o:Ol2) 
effect  o  =  make_ni(x) 

op  maJce_n2(c:Ol2Class,  x:  S2)  returns(o:0l2) 
effect  o  =  make_n2(x) 

op  hasTag?(o;012,  t:  Tag)  returns(b:Bool) 
effect  b  =  hasTag?(o,  t) 

op  value[T](o:0l2,  t:  Tag)  returns(r:T) 
requires  hasTag?(o,  t) 

&  ((t  =  ni)  Si  <  T) 

&  ((t  =  02)  S2  <  T) 

effect  ((t  =  ni)  =>  r  =  val-ni(o)) 

&:  ((t  =  n2)  =?►  r  =  val-n2{o)) 
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from  the  specification  S,  then  that  type  is  a  type  whose  carrier  set  in  all  S-algebras  is 
flat.  For  example,  we  would  disallow  QneOf  [b;BoolStream,i  ilntStream]  as  a  type  of 
0,  because  the  carrier  sets  of  BoolStream  and  IntStream  are  not  flat.)  Let  NomSig  be 
the  nominal  signature  map  of  0. 

We  inductively  define  a  presumed  subtype  relation  <  on  the  types  of  0  as  follows. 
As  the  basis,  for  all  types  SI  and  S2  from  the  specification  S,  SI  <  S2  if  and  only  if 
SI  <s  S2.  Furthermore,  Tag  <  Tag,  TagClass  <  TagClass,  and  for  all  class  types 
□Class  introduced  by  0,  GClass  <  GClass.  For  the  GneOf  types  introduced  by  the 
specification  O, 

GneGffm  :  Sj,..  .,nj  :  Sj]  <  □neGf[ni  ;  Ti, . . . ,  nj  :  Tj, . . . ,  nk  ;  T^] 
^V(ie{l,...,j})Si<Ti. 

That  is,  for  GneGf  types,  one  type  is  related  by  <  to  another  only  if  the  first  has  a  subset 
of  the  second’s  tags  and  the  corresponding  types  are  related  by  <.  Note  that  we  do  not 
allow  GneGf  types  to  be  recursively  defined. 

The  next  lemma  says  that  <  is  a  subtype  relation  with  respect  to  the  set  of  type-safe 
NOAL  programs  over  NomSig  and  <.  In  the  proof  we  inductively  build  a  simulation 
relation  with  the  properties  required  to  show  that  <  is  a  subtype  relation. 

Lemma  6.4.2.  The  relation  <  described  above  is  a  subtype  relation  on  the  types  of  O 
with  respect  to  the  set  of  type-safe  NOAL  programs  over  NomSig  and  <. 

Proof:  Let  C  be  an  0-algebra.  Let  C^s)  be  the  SIG{S)-red\ici  of  C.  Since  <5  is  a 
subtype  relation,  there  is  some  S-algebra  A(s)  such  that  every  environment  over  C(s)  that 
obeys  <5  imitates  a  nominal  environment  over  A(s).  Since  the  specification  of  a  GneGf 
type  of  the  form  GneGf  [nl  :S1,. .  .,nk:Sk]  does  not  constrain  the  types  Si,  there  is  some 
0-algebra  A  whose  5/6’( 5)- reduct  is  A(s).  Without  loss  of  generality,  we  can  assume  that 
each  value  [J’]  operation  of  A  is  maximally  nondeterministic  when  its  requires  clause 
is  not  satisfied,  because  this  behavior  is  permitted  by  our  specification  of  GneGf  types. 

We  define  a  homomorphic  relation  between  C  and  A  for  NomSig  and  <  as  follows. 

First  some  terminology.  We  say  that  a  GneGf  object  o  has  tag  t  if  the  result  of 
Af  [hasTag?(o,  tjKC,  r;o)  is  true,  where  r]o{o)  =  o.  We  say  that  value [T]  (o,t)  is  q  if 
the  only  possible  result  of  7V([value[T](o,  tjKC,  ?7o)  is  q,  where  //o(o)  =  o. 
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By  our  assumption  above,  there  is  a  simulation  relation  between  C(s)  and  i4(s) 
that  witnesses  <s.  We  define  a  homomorphic  relation  72.  between  C  and  A  by  structural 
induction  on  type  expressions  to  be  the  smallest  typed  family  of  relations  between  C  and 
A,  sucli  that: 

•  72'^  C  72;  that  is,  if  T  is  a  type  of  the  specification  S,  then  72t  contains  72f- 

•  Let  Oi  =  OneOf[ni  :  Sl,...,nj  :  Sj]  be  a  OneOf  type  introduced  by  0.  Then  72oj 
is  such  that  q  72o,  r  ii  q  and  r  are  both  1.  or  q  and  r  are  proper  instances  of  some 
OneOf  type  introduced  by  0  such  that  q  and  r  have  the  same  tag,  which  is  some 
Hi  in  the  set  of  tags  of  Oi  and 


value(Si](^,ni)  =  q' 

(6.31) 

value[Si](r,ni)  =  r' 

(6.32) 

q'  72si  r'. 

(6.33) 

•  For  all  class  types  QClass  introduced  by  0,  72ociaB8  is  such  that  ±  in  C  is  related 
to  ±  in  A  and  the  only  proper  object  of  type  OClass  in  C  is  related  to  the  proper 
object  of  type  OClass  in  A. 

•  We  have  not  specified  the  type  Tag  in  detail.  But  let  us  agree  that  it  is  gen¬ 
erated  by  class  operations  of  the  form  t(Tag),  which  we  abbreviate  to  t  for 
all  “tag  names”  t.  Furthermore,  two  tag  objects  are  the  same  only  if  they  are 
the  result  of  the  same  operation  t(Tag).  We  define  72Tag  as  the  smallest  rela¬ 
tion  between  the  carrier  sets  of  Tag  in  C  and  A  such  that  for  all  tag  names  t, 
^Mlt(Tag)](C,  0)  72Tag  A4[t(Tag)J(A, 0).  That  is,  72Tag  only  relates  one  tag  object 
to  another  if  both  are  the  “same  tag.” 

Before  showing  that  72  is  a  homomorphic  relation,  we  first  need  to  show  that  72 
witnesses  <  and  satisfies  Formula  6.1.  This  is  proved  by  a  (double)  structural  induction 
on  type  expressions.  That  is,  we  show  for  all  types  T  and  for  all  types  S  such  that  S  <  T, 
that  72  witnesses  <  and  that  Formula  6.1  holds.  As  a  beisis,  the  claim  holds  for  all  types 
introduced  by  the  specification  S,  since  72^  satisfies  the  claim  by  hypothesis.  The  type  Tag 
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is  only  related  to  itself  by  <  and  by  construction  CTagT^Tag^Tag-  F'urthermore,  a  class  type, 
introduced  by  O  is  related  only  to  itself  by  <,  and  by  construction  CociaBs^ociaas'dociasB- 

For  the  inductive  step,  let  Oi  and  O2  b(r  OneOf  types  introduced  by  the  specification 
O  sucli  that  Oi  <  O'i  and  assume  for  all  their  component  types  S  and  T  Formulas  6.1  and 
G.16  hold.  Since  Oi  <  O2,  Oi  must  have  the  form  OneDf[ni  :  Si, . . .  ,nj  :  Sj]  and  O2  m  ust 
have  the  form  0ne0f[ni  ;Ti,...,nj  :Tj,...,nk  :  Tk]  where  for  t  from  1  to  j,  Si  <  Ti. 
'I'hc  imluctive  assumj>tion  is  tliat  tlie  formulas  hold  for  each  pair  of  types  Si  <  Ti  where 
?  G  {l,...,j}.  Then  C'o,  'Roj  because  Oi  has  a  subset  of  the  tags  of  O2,  and  so 
every  proper  element  of  C'o,  has  the  tag  of  some  proper  element  of  Ao2f  a.nd  because  its 
value  at  that  tag  is  related  to  some  element  in  A  by  where  Si  is  the  type  associated 
with  the  tag.  Suppose  f/Ro,  Then  by  construction,  q  and  r  have  the  same  tag,  say  ni, 
and  their  values  at  that  tag  are  related  by  Rs^-  By  the  inductive  hypothesis,  Rs^  C  Rt^, 
so  their  values  at  that  tag  are  related  by  Rj^.  So  qRo,  r  by  construction  and  therefore 

Ro,  S 

We  now  show  that  R  is  a  homomorphic  relation.  Let  X  and  environments  7/1  G 
ICNV{X ,C)  and  772  €  ENV{X ,  A)  be  such  that  771  7?.  772.  Suppose  g(x)  is  a  generic 
invocation  of  some  nominal  type  T.  If  T  is  not  a  OneOf  type  and  none  of  the  identifiers 
in  X  has  a  OneOf  type,  then  for  each  x,  :  T,,  77i{x,)  R^^  ^2{xi)>  because  R  does  not  relate 
proper  instances  of  OneOf  types  at  the  types  of  S  and  because  771  R  ^2-  Since  R^  is  a 
homomorphic  relation,  we  have  Ad|g(x)J(C,  771)7^7  A1[g(x)J (/1, 772).  So  it  remains  to  deal 
with  generic  invocations  involving  the  OneOf  types.  There  are  several  cases. 

•  The  generic  invocation  is  make-n(x,y)  for  some  tag  name  n  and  some  identifiers 
X  :  OneOf  [...,  n  :  T, ..  .jClass  and  y  :  S  where  S  <  T.  This  generic  invocation 
has  nominal  type  OneOf  [...  ,  n:T,  ...].  Since  771  7?.  772,  771  (y)  7?.s  772(y),  and  thus 
Viiy)  V2iy],  because  (S  <  T)  =»  Rs  C  Rj.  So  by  definition  of  R  at  OneOf  types, 

AI|inake-n(x,y)l(C',77i)  7^oneOf[....n:T,...]  A1[make_n(x,y)](/1, 772).  (6.34) 

•  The  generic  invocation  is  hasTag?(x,y)  for  some  OneOf  type  Oi  and  some  iden¬ 
tifiers  X  :  0\  and  y  :  Tag.  This  generic  invocation  has  nominal  type  Bool. 
Since  rji  R  772,  ?7i(y)  and  T}2{y)  must  denote  the  same  tag  name.  Further¬ 
more,  R  only  relates  objects  at  a  OneOf  type  if  they  have  the  same  tag.  So 
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>f[hasTag?(x,y)|(C,r/i)  =  A<[hasTag?{x,  y)|(>l,  72)-  Since  TIbooI  is  the  identity, 
we  have 

7V^[hasTag?(x,y)](C',7l)7^Bool  /d[hasTag?(x,y)l(/l,72)-  (6.35) 

•  The  generic  invocation  is  valued]  (x,y)  for  some  type  T,  some  OneOf  type  Oi, 
and  some  identifiers  x  ;  Oi  and  y  :  Tag.  This  generic  invocation  has  nominal 
type  T.  Since  r/i  %  t)2,  7i(y)  and  72(y)  denote  the  same  tag  name.  Therefore,  the 
requires  clause  for  the  appropriate  value  d]  operations  is  satisfied  in  C  if  and  only 
if  it  is  satisfied  in  A.  We  chose  A  so  that  the  valued]  operation  is  maximally 
nondeterministic  when  its  requires  clause  is  not  satisfied;  therefore,  if  the  requires 
clause  is  not  satisfied,  every  element  of  the  result  in  C  is  related  to  some  element  of 
the  result  in  A  by  'JZy,  because  <  is  reflexive  and  Ct'R.tAj.  So  suppose  the  requires 
clause  is  satisfied;  that  is,  suppose  that  both  7i(x)  and  t}2{x)  have  tag  72(7)-  By 
definition  of  it  must  be  that 

Al[value[T](x,y)l(C,7i)'llT  X(value[T](x,y)l(i4,72)  (6.36) 

So  72.  is  a  homomorphic  relation. 

The  relation  72  is  also  a  simulation  relation.  It  is  V-identical,  because  72^  is  V- 
identical  and  72  does  not  add  new  relationships  between  proper  elements  of  the  visible 
types.  It  is  also  bistrict  and  satisfies  Formula  6.1  by  construction. 

Since  72  is  a  simulation  relation  that  witnesses  <,  by  Theorem  6.3.2,  it  follows  that 
<  is  a  subtype  relation  with  respect  to  type-safe  NOAL  programs  over  NomSig  and  <.  I 

6.4.3  Exceptions 

As  discussed  in  Chapter  5,  a  subtype  may  have  fewer  exceptions  than  its  supertypes. 
In  this  section  we  show  that  this  rule  also  holds  with  respect  to  all  type-safe  NOAL 
programs. 

Consider  again  the  specification  M4,  which  consists  of  the  types  Mob  and  Mob3  as 
specified  in  Figure  2.6  on  page  39  and  Figure  5.4  on  page  95.  The  type  Mob3  is  like 
Mob,  except  that  it  can  also  signal  an  exception  “empty(nil).”  It  does  this  by  returning 
the  denotation  of  madce.emptyCNE, nil  (Null))  instead  of  meLke-normal(NE,i) ,  for  some 


integer  i  (where  NE  abbreviates  OneOf [normal :  Int,  empty:  Null]).  Since  we  are 
concerned  with  exceptions,  we  again  consider  that  the  return  type  of  the  next  operation 
of  type  Mob  is  OneQf  [normal :  Int].  Let  NomSiy  be  the  nominal  signature  map  of  M4. 
Let  <  be  the  smallest  reflexive  relation  on  the  types  of  M4  such  that  Mob  <  Mob3  and 

OneOf  [normal  :  Int]  <  OneOf[normal  :  Int,  empty  :  Null]. 

Unlike  the  previous  section,  the  types  Mob3  and  Mob  are  specified  using  the  OneOf  types. 
Therefore  we  cannot  separate  tiie  proof  of  a  subtype  relationship  for  M4  into  a  proof  for 
non-OneOf  types  and  a  proof  for  OneOf  types,  as  in  the  previous  section. 

Let  C  be  an  M4-algebra.  Let  A  be  an  M4-algebra  with  the  same  carrier  sets  and  ab¬ 
stract  functions  as  C  but  with  a  maximally  nondeterministic  nextMobS— int  and  value]!] 
operations.  Such  an  M4-algebra  exists,  because  of  the  way  the  types  are  specified. 

We  define  a  simulation  relation  Ti.  between  C  and  A  for  NomSig  and  <  as  follows. 
Let  TZ  be  the  smallest  typed  family  of  relations  between  C  and  A  such  that 

•  for  each  type  T,  T^t  contains  the  identity  on  Ct  (which  is  the  same  as  Ay), 

•  ‘^Mob3  relates  all  proper  instances  of  Mob  to  instances  of  either  Mob3  or  Mob  with  the 
same  elements  (waiting  integers),  and 

•  'T^OneOf  [normai:lnt,empty;Nuii]  relates  each  instance  q  of  OneOf  [normal :  Int]  such  that 
value  [Int]  iq,  normal)  is  some  integer  i  both  to  itself  and  also  to  all  instances  r  of 
OneOf  [normal :  Int,  empty:  Null]  with  the  same  tag  such  that  value  [Int]  (r, 
normal)  is  i. 

It  is  straightforward  to  show  that  7?.  is  a  homomorphic  relation.  Clearly  TZ  is  also  V- 
identical,  bistrict  and  satisfies  Formula  6.1.  So  7^  is  a  simulation  relation. 

By  construction  TZ  witnesses  <  and  so  <  is  a  subtype  relation  on  the  types  of  Ml 
with  respect  to  all  type-safe  NOAL  programs  over  NomSig  and  <. 


Chapter  7 

Hoare- style  Verification  for  NOAL  Programs 


In  this  chapter  we  present  a  Hoare  logic  for  the  verification  of  NOAL  programs.  The 
key  idea  is  using  simulation  relations  to  translate  assertions  tailored  to  a  subtype  into 
assertions  tailored  to  a  supertype.  We  also  draw  some  conclusions  about  how  a  type 
system  aids  verification  and  discuss  the  role  that  observable  assertions  play  in  verification. 

Our  verification  technique  has  the  property  that  if  a  subtype  is  not  explicitly  used  in  a 
NOAL  function  definition,  then  it  is  ignored  during  verification  of  that  function.  Because 
of  this  property,  if  one  verifies  a  NOAL  function  and  then  later  adds  new  subtypes  to 
some  of  the  function’s  nominal  argument  types,  then  the  verification  does  not  have  to  be 
repeated. 

As  usual,  the  specifications  of  each  type’s  operations  and  the  specification  of  each 
recursively-defined  NOAL  function  is  an  axiom.  The  axiom  used  for  a  particular  generic 
invocation  is  determined  by  the  nominal  type  of  the  generic  invocation’s  first  argument 
(that  is,  using  static  instead  of  dynamic  overloading).  When  the  program  explicitly 
passes  an  expression  of  nominal  type  S  as  an  argument  when  the  nominal  type  of  the 
corresponding  formal  argument  is  T,  simulation  relations  are  used  to  translate  knowledge 
about  the  actual  expression  from  type  S  to  type  T. 

A  verification  technique  for  NOAL  programs  is  sound  if  whenever  one  concludes  by 
using  that  technique  that  a  program  satisfies  its  specification  with  respect  to  the  set  of 
all  type-safe  NOAL  programs,  then  that  program  does  indeed  satisfy  its  specification. 
After  presenting  our  Hoare  logic,  we  show  that  it  is  sound. 
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7.1  A  Hoare  Logic  for  NOAL 

In  this  section  we  give  a  Hoare  logic  [Hoa69]  for  NOAL  programs.  We  take  a  total  cor¬ 
rectness  approach,  since  our  specifications  require  termination  whenever  the  precondition 
is  met.  Our  logic  is  sound,  but  it  is  not  complete,  since  we  are  unable  to  reason  about 
nontermination  as  would  be  required  to  deal  with  NOAL’s  lazy  evaluation  and  angelic 
choice  e.xpressions  in  a  complete  way. 

Although  NOAL  is  applicative,  we  use  a  Hoare  logic  because  NOAL  is  nondetermin- 
istic  and  because  we  are  ultimately  interested  in  verification  of  imperative  programs,  for 
which  Hoare-style  reasoning  is  an  accepted  technique. 

The  fundamental  formulcis  of  a  Hoare  logic  are  called  Hoare-triples.  Hoare-triples  are 
written  P  {v  E)  Q  and  consist  of  a  precondition  P,  a  result  identifier  v,  an  expression 
E,  and  a  postcondition  Q.  (The  name  of  the  result  identifier  can  be  chosen  at  will.)  In 
a  Hoare  logic  for  an  imperative  language,  the  precondition  describes  the  state  before  the 
execution  of  a  statement,  and  the  postcondition  describes  the  changed  state  that  results 
from  the  statement’s  execution.  In  NOAL,  however,  expressions  have  results  but  do  not 
change  the  environment  in  which  they  execute.  So  in  our  logic,  the  precondition  of  a 
Hoare-triple  describes  the  environment,  and  the  postcondition  describes  the  environment 
that  results  from  binding  the  possible  results  of  the  expression  to  the  result  identifier 
(v).  So  that  the  notation  does  not  cause  confusion,  the  result  identifier  in  a  Hoare-triple 
cannot  occur  free  in  the  precondition.  Otherwise  one  might  think  that  the  execution  of 
E  changes  the  binding  of  the  result  identifier  in  the  surrounding  environment,  whereas 
we  are  only  using  suggestive  notation  that  shows  what  identifier  will  be  used  to  denote 
the  possible  results  of  E  in  the  postcondition. 

Definition  7.1.1  (Hoare-triple  for  SPEC),  Let  SPEC  be  a  specification.  Then 
P  {y  *—  E]  Q  is  a.  Hoare-triple  for  SPEC  if  and  only  if  P  is  a  type-safe  NOAL  ex¬ 
pression  P  and  Q  are  SPEC -assertions,  y  has  the  same  nominal  type  as  E,  and  y  does 
not  occur  free  in  P. 

We  do  not  mention  the  specification  name  when  it  is  clear  from  context. 

Intuitively,  P  {v  E}  Q  is  true  if  whenever  P  holds,  then  thfe  execution  of  E 
terminates,  and  all  possible  results  satisfy  Q.  The  semantics  of  a  Hoare-triple  is  given 
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by  the  following  definition,  which  is  similar  to  the  definition  of  satisfies  for  function 
specifications. 

Definition  7.1.2  (models  for  Hoare-triples).  Let  SPEC  be  a  specification.  Let 
P  {v  <—  E}  be  a  Hoare-triple  for  SPEC.  Let  X  be  a  set  of  free  identifiers  that 
contains  all  the  free  identifiers  of  P,  P,  and  Q  except  v.  Let  /I  be  a  5PPC-algebra,  and 
T]  6  ENV{X ^  A)  an  environment  that  is  proper  and  obeys  the  presumed  subtype  relation 
of  SPEC.  Let  T)'  be  the  environment  that  extends  rj  by  binding  each  free  function  iden¬ 
tifier  in  E  to  the  denotation  in  A  of  the  corresponding  recursive  function  definition.  We 
say  that  {A,r})  models  P  {v  *—  E)  Q  and  write 

{A,n)\^P  {v^E)Q 

if  and  only  if  whenever  (A,?;)  [=  P,  then  for  all  possible  results  q  G  M\E\{A,ti')  the 
following  hold: 

q  ±  (7.1) 

(Avl«/vl)  1=  Q.  (7.2) 

For  example,  the  Hoare-triple  “P  {v  ♦—  E}  true”  means  that  evaluation  of  E  in 
environments  that  model  P  terminates,  since  every  algebra-environment  pair  models  the 
postcondition  “true.”  If  the  precondition  P  is  not  logically  equivalent  to  “false,”  then 
there  are  no  expressions  E  such  that  “P  {v  *—  E}  false”  is  valid,  because  no  algebra- 
environment  pair  models  the  assertion  “false.”  However,  for  all  expressions  E  and  all 
assertions  Q,  every  algebra-environment  pair  models  the  Hoare-triple  “false  {v  E}  Q," 
since  the  precondition  “false”  cannot  be  satisfied. 

We  say  that  the  Hoare-triple  P  {v  E}  Q  is  valid  and  write  SPEC  \=  P  {v  E}  Q 
when  for  all  5PPC'- algebras  A  and  for  all  environments  q  G  ENV  (A',  >1)  such  that  X 
contains  the  free  identifiers  of  P  and  E  and  Q,  q  is  proper,  and  q  obeys  the  presumed 
subtype  relation  of  SPEC,  {A,q)  \=  P  {v  E]  Q. 

Figures  7.1  and  7.2  contain  the  proof  rules  for  NOAL  expressions.  In  these  figures, 
P,  Q,  and  R  are  assertions,  M  is  &  term,  and  E,  Ei,  and  so  on  are  NOAL  expressions. 
The  notation  h  H,  where  //  is  a  Hoare-triple,  means  that  one  can  prove  H  using  the 
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Figure  7.1:  Axiom  Schemes  for  verification  of  NOAL  Expressions. 


[ident] 

h  true  {v  <— 

x}  M[v/z]  =  A/[x/z] 

x,v,z  :  T 

[hot] 

f-  false  {v  <— 

bottom [T]}  true 

[ngop] 

h  true  {v  <— 

TO}  v  =  T 

[ginvoc-a] 

>■  Pre(gg_T)  {y  ^  gCx)}  Post(gg_T.) 

Pre(gg_^T)  observable, 

X  :  S  and  y  :  T  formals 
of  spec  of  gg_x 

[fcall-a] 

h  Pre(f)  {y 

f  (x)}  Post(f) 

Pre(f)  observable, 

X  :  S  and  y  :  T  formals 
of  spec  of  f 

proof  rules.  A  proof  rule  of  the  form: 

c 

means  that  to  prove  the  conclusion  c  one  must  first  show  that  both  hypotheses  h\  and 
h2  hold.  Rules  written  without  hypotheses  and  the  horizontal  line  are  axiom  schemes. 

Each  rule  is  named,  for  convenience  in  proofs.  The  name  of  a  rule  appears  to  the  left 
of  that  rule.  To  the  right  of  some  of  the  rules  are  conditions  on  types  and  identifiers. 
Some  of  the  conditions  require  an  identifier  to  be  frtsh,  which  means  it  is  not  in  the  set  of 
free  identifiers  of  either  the  desired  precondition  (written  P  in  the  figures)  or  the  desired 
postcondition  {Q). 

In  the  following  list  we  discuss  each  of  the  rules  in  Figures  7.1  and  7.2  and  explain 
the  conditions  that  accompany  each  rule.  In  the  discussion  we  fix  a  specification  SPEC 
with  presumed  subtype  relation  <.  All  assertions  mentioned  are  SPEC -assertions. 

•  The  rule  [ident]  is  an  axiom  scheme  for  all  types  T,  for  all  identifiers  x  and  v  of 
nominal  type  T,  and  for  all  terms  M.  The  notation  M[x/z]  means  M  with  all  free 
occurrences  of  z  replaced  by  x. 

The  rule  says  that  the  only  possible  result  of  an  expression  x  is  tiie  value  of  x. 
Furthermore,  it  allows  one  to  draw  immediate  consequences  of  the  equality  of  v 


143 


Figure  7.2:  Inference  rules  for  verification  of  NOAL  expressions. 


[ginvoc-b] 

f-P{y^(fun  (x:S)  g(x))  CE)}  Q 

E-.a, 

hP{y^g(E)}Q 

(T  <  S,  <Ti  =  Si 

[fcall-b] 

h  P  {y  <-  (fun  (x  :  S)  f(x))  (E)]  Q 

E:a, 

hP  {y^f(P)}  Q 

a  <S 

1-  P  {Vi  ^  Pi}  Pi,  ...,  h  P  K  ^  ^n}  Rn, 

Vi  IZs,  Xi  h  Pi[z/x]  P'l, 

[comb] 

Vn  'R-S„  Xn  F  Pn[z/^  =»  P'„, 
h  Pi  &  •  •  •  kR'n  {y[z/i]  Po}  <3[z/x] 

z  :  S  fresh 

|-P{y^(fun  (x:S)  Po)  (Pi, . . . ,  P„)}  Q 

[if] 

F  P  {v  <—  Pi}  true, 

F  P  &  Pi  {v  ♦—  Pi}  v  =  true,  F  P  &  Pi  {y  ♦—  P2}  Q, 

F  P  &  P2  {v  Pi}  v  =  false,  F  P  &  P2  {y  ♦—  P3}  Q 
FP&P3  {y  ^Pj}  Q,  FPfcPa  {y  ^  P3}  Q 

F  (P1IP2IP3)  =  true 

F  P  {y  4—  if  Pi  then  P2  else  P3  fi}  Q 

[erratic] 

hP{y*-Et}Q,\-P{y*-E,}Q 

FPTTTr^npjlQ 

[angelic] 

t-P{y^Ei}Q,\-P{y^E2]Q 

h  P  {y  ^  Ei^  E2}  Q 

[isDef] 

F  P  {y  4—  P}  true 

F  P  {y  4—  isDef?(P)}  y  =  true 

[conseq] 

F  P  =»  Pi,  F  Pi  {y  4-  P}  gi, 

-f* 5  -fi»  Qj  Qi 

observable, 
y  not  free  in  P 

t-P{y^E]Q 

[carry] 

observable 

[rename] 

t-P{y^E)Q 

P  and  g 

X  :  f 

F  P  {y  4-  P}  P&g 

F  P[z/x]  {y[z/x|  4-  P[z/x]}  g[z/x] 

1-  />  {y  .-  £}  0 

z  :  f  fresh 
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and  X.  This  is  useful  because  sometimes  “v  =  x”  is  not  observable  and  the  rule  of 
consequence  (below)  does  not  allow  one  to  use  assertions  that  are  not  observable. 

•  The  rule  [bot]  says  that  the  execution  of  bottom  [T]  never  terminates. 

•  The  rule  [ngop]  is  an  axiom  scheme  for  all  type  symbols  T  in  the  specification  SPEC. 
(Recall  that  T()  is  the  desugared  form  of  the  expression  T.)  The  rule  [ngop]  says 
that  this  invocation  returns  the  class  object  with  the  same  name. 

•  The  rule  [ginvoc-a]  is  an  axiom  scheme  for  all  operation  specifications  of  SPEC.  We 
denote  by  Pre(gg_^.j.)  the  precondition  of  the  operation  specification  named  g  with 
nominal  signature  S  — >  T.  Similarly,  Post(gg_^.j.)  is  that  operation’s  postcondition. 
Notice  that  the  axiom  only  describes  the  effect  of  a  generic  invocation  where  the 
actual  argument  expressions  and  the  result  identifier  are  exactly  the  same  as  the 
formal  arguments  and  the  formal  result  used  in  the  specification  of  g  (with  nominal 
signature  S  — >  T). 

For  soundness,  we  require  that  the  precondition  of  this  axiom  scheme  be  observable. 
This  restriction  ensures  that  the  precondition  is  meaningful  even  when  the  actual 
arguments  do  not  have  the  nominal  types  of  the  formals. 

•  The  rule  [fcall-a]  is  an  ajciom  scheme  for  all  recursively-defined  NOAL  functions. 
The  precondition  and  postcondition  of  a  function  come  from  its  specification.  As 
with  [ginvoc-a],  we  require  that  the  precondition  of  this  axiom  scheme  be  observable. 

•  The  inference  rule  [ginvoc-b]  handles  the  general  form  of  a  generic  invocation.  To 
prove  a  triple  involving  a  generic  invocation  one  is  obliged  to  first  rewrite  the  generic 
invocation  from  its  general  form  into  one  where  the  actual  argument  expressions  are 
first  bound  to  identifiers.  The  types  of  these  identifiers  must  be  chosen  carefully  so 
that  an  instance  of  the  rule  [ginvoc-a]  will  apply.  However,  since  we  wish  to  reason 
beised  on  nominal  type  information  and  since  the  nominal  type  of  the  first  argument 
determines  the  nominal  type  of  the  result  in  NOAL,  the  nominal  type  of  the  first 
argument  cannot  be  changed.  Furthermore,  the  types  of  the  other  arguments  are 
constrained  so  that  the  rewritten  expression  type-checks. 
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•  The  inference  rule  [fcall-b]  is  like  [ginvoc-b]  in  that  it  requires  one  to  rewrite  a 
general  function  call  so  that  the  argument  expressions  are  first  bound  to  identi¬ 
fiers.  These  identifiers  should  be  chosen  to  match  the  formal  arguments  from  the 
specification  of  the  function. 

•  The  inference  rule  [comb]  handles  combinations  that  may  include  coercions  between 
types.  The  rule  as  a  whole  says  that  to  prove  that  the  desired  triple  holds,  one 
must  first  characterize  each  actual  argument  expression  Ei  with  some  assertion  Ri 
according  to  the  nominal  type  of  Ei.  Then  one  must  translate  each  Ri  into  an 
assertion  that  describes  the  actual  argument  according  to  the  nominal  type  of 
the  corresponding  formal,  Xj.  This  translation  uses  the  axioms  that  characterize 
a  simulation  relation.  We  will  have  more  to  say  about  such  translations  below. 
Finally  one  must  prove  that  the  conjunction  of  the  R'i  is  strong  enough  to  show  that 
the  possible  results  of  the  body  of  the  combination  satisfy  the  desired  postcondition. 

The  fresh  identifiers  z  are  used  to  hide  bindings  of  x  in  the  cissertions  so  that  the 
proper  scope  applies.  The  notation  y[z/x]  means  z,-  if  for  some  i,  x,-  is  y.  The 
identifiers  z,  must  be  fresh  to  avoid  capture  problems. 

•  The  inference  rule  [if]  allows  one  to  reason  about  if  expressions  whose  boolean 
expression  (F?i)  may  be  nondeterministic.  Before  explaining  the  rule  in  general  we 
consider  two  special  cases. 

If  the  boolean  expression  Ei  is  deterministic,  let  the  assertion  R3  be  “false”  2ind  let 
be  -<Ri.  The  assertion  Ri  must  then  characterize  the  value  of  Ei  in  the  following 
sense.  If  the  desired  precondition  and  Ri  both  hold,  then  the  only  possible  result  of 
El  is  true,  otherwise  if  the  desired  precondition  and  ->i?i  both  hold,  then  the  only 
possible  result  of  Ei  is  false.  Then  one  has  to  prove  that  the  desired  precondition 
and  Ri  together  are  strong  enough  to  show  that  the  desired  postcondition  holds 
on  the  results  of  Ei  (the  “true”  arm)  and  that  the  desired  precondition  and  -iRi 
are  strong  enough  to  make  the  postcondition  hold  on  the  result  of  E3  (the  “false” 
arm).  Since  R3  is  “false”  and  Ri  =  ~'Ri,  the  other  hypotheses  follow  trivially. 

If  the  boolean  expression  Ei  has  as  possible  results  bot  true  and  false  when  the 
desired  precondition  holds  (e.g.,  if  Ei  is  true  []  false),  then  let  Ri  and  Ri  be 


“false”  and  let  R3  be  “true.”  One  must  then  show  that  Ei  terminates  and  that 
the  possible  results  of  both  E2  and  E3  satisfy  the  desired  postcondition  when  the 
desired  precondition  holds.  The  other  hypotheses  follow  trivially. 

In  general,  the  assertion  Ri  should  characterize  when  E\  has  true  as  its  only  possible 
result,  should  characterize  when  E\  has  false  as  its  only  possible  result,  and 
should  characterize  when  Ei  is  nondeterministic.  Then  one  has  to  show  that 
El  terminates,  that  in  each  case  the  postcondition  follows,  and  that  all  cases  are 
covered.  One  shows  that  all  cases  are  covered  by  showing  that  (i2ili?2|.R3)  =  true. 

The  inference  rule  [erratic]  says  that  the  desired  postcondition  must  follow  from 
the  desired  precondition  for  each  expression. 

The  inference  rule  [angelic]  is  analogous  to  the  rule  [erratic].  Although  this  rule 
is  sound,  it  fails  to  capture  all  the  semantics  of  angehc  choice  in  NOAL.  That  is, 
an  angelic  choice  expression  where  only  one  subexpression  might  fail  to  terminate 
would  still  terminate,  but  our  rule  requires  that  both  subexpressions  terminate. 
This  incompleteness  is  caused  by  the  inability  of  our  logic  to  describe  the  possible 
results  of  an  expression  separately  from  its  termination. 

The  inference  rule  [isDef]  says  that  to  prove  that  an  isDef?  expression  halts  (with 
value  true),  one  must  prove  that  all  the  possible  results  of  the  argument  expression 
are  proper. 

The  general  inference  rule  [conseq]  is  standard  for  Hoare  logics,  where  it  is  often 
called  the  “rule  of  consequence”  [Hoa69].  It  allows  us  to  use  a  stronger  precondition 
and  a  weaker  postcondition.  The  implications  that  appear  in  the  hypothesis  must 
be  provable  from  the  traits  of  the  referenced  specification,  using  the  proof  rules  and 
axioms  of  those  traits. 

There  are  two  conditions  that  apply  to  this  rule.  First,  the  preconditions  and 
postconditions  mi.  '  observable.  This  restriction  ensures  that  implication  has 
the  expected  meaning.  Second,  the  result  identifier  must  not  appear  free  in  P;  this 
ensures  that  the  conclusion  is  well-formed. 
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•  The  inference  rule  [carry]  allows  us  to  carry  observable  assertions  from  the  precon¬ 
dition  into  the  postcondition.  We  only  allow  observable  assertions  to  be  carried 
into  the  postcondition,  because  only  observable  properties  that  hold  in  an  environ¬ 
ment  are  guaranteed  to  hold  when  that  environment  is  extended  with  a  possible 
result  and  because  observability  ensures  that  conjunction  has  the  expected  meaning. 
However,  observable  preconditions  are  preserved  by  expressions,  because  NOAL  is 
an  applicative  language. 

•  The  inference  rule  [rename]  allows  us  to  consistently  rename  identifiers. 

A  proof  in  our  logic  may  also  use  formulas  that  are  provable  from  the  traits  of  the 
referenced  specification.  (Such  formulas  are  used  as  hypotheses  in  the  rules  [conseq]  and 
[if].)  These  traits  always  include  the  trait  Bool  and  the  equality  trait.  The  equaUty  trait 
allows  us  to  interpret  the  relation  “=”  that  appears  in  terms  as  a  congruence  relation. 

Formally,  a  proof  of  a  Hoare-triple  for  SPEC  is  a  list,  where  the  last  line  in  the  list 
is  the  desired  Hoare-triple  and  each  line  in  the  list  is  either: 

•  a  formula  of  the  form  F  Q,  where  Q  is  a  SPEC -assertion  that  is  provable  from  the 
traits  of  SPEC, 

•  a  translation  axiom  of  the  form  v  TZs  x  \-  P'  Q'  where  P'  and  Q'  are  SPEC- 
assertions  (as  discussed  below),  or 

•  a  formula  of  the  form  h  P'  {y  E'}  Q\  where  P'  {y  *—  E')  Q'  is  a  Hoare-triple 
for  SPEC,  and  the  formula  either  is  an  axiom  or  follows  from  some  previous  lines 
by  the  inference  rules  of  our  logic. 

We  tranalate  assertions  about  subtypes  into  assertions  about  their  supertypes  using 
simulation  relations.  The  translations  are  used  in  the  inference  rule  [comb],  where  they 
appear  as  formulas  of  the  form: 


xTZsyh  P(x)  Q(y). 


The  above  formula  means  that  if  the  value  of  x  :  cr  simulates  the  value  of  y  :  S  at  type  S 
and  P(x)  holds,  then  Q(y)  holds. 
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For  example,  in  the  proof  of  a  program  that  referenced  the  specification  IPT  we  would 
use  the  following  formulas  for  translating  assertions  about  instances  of  IntTriple  into 
cissertions  about  instances  of  IntPair: 


■t  'T^intPair  P  ^  t. first  =  i  =>  p. first  =  i  (7.3) 

■t  ^latPair  p  h  t.second  =  i  p.second  =  i.  (7-4) 

where  t  ;  IntTriple,  p  :  IntPair,  and  i  :  Int.  These  formulas  should  be  thought  of  as 
universally  quantified  over  the  identifiers  involved;  that  is,  the  identifier  names  do  not 
matter. 

A  proof  in  our  logic  may  use  such  a  formula  as  an  axiom  when  the  following  conditions 
hold.  Let  SPEC  be  a  fixed  specification.  Let  <  be  the  presumed  subtype  relation  of 
SPEC  and  let  NomSig  be  the  nominal  signature  map  of  SPEC.  Consider  the  formula: 

x7^syFP=^Q  (7.5) 

where  P  and  Q  are  5PEC-assertions,  x  :  a  does  not  appear  free  in  Q,  and  y  :  S  does  not 
appear  free  in  P.  We  take  the  above  formula  as  an  axiom  if  and  only  if  for  all  SPEC- 
algebras  C,  there  is  some  SPEC-aUgehta.  A,  such  that  there  is  a  simulation  relation 
TZ  between  C  and  A  for  NomSig  and  <  such  that  TZ  witnesses  <,  and  the  following 

property  holds  for  all  such  A  and  all  such  IZ:  for  all  sets  of  typed  identifiers  Z  that 

includes  the  free  identifiers  of  P  and  Q  except  x  :  a  and  y  :  S,  for  all  environments 
gc  €  ENV(Z  U  {x  :  o’},C)  and  G  ENV{Z  U  {y  :  S},y4)  such  that  r/c  is  proper,  r/c 
obeys  <, 


{C,r,c) 

1= 

p, 

(7.6) 

Vc(x) 

ns 

VA{y), 

(7.7) 

and  for  each  type  T  and  for  each  identifier  z  :  T  €  2^, 

ric{z)7ZTTiA{z),  (7.8) 


it  follows  that 


(=  Q. 


(7.9) 
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As  a  practical  matter,  we  expect  that  a  small  set  of  axiom  schemes  should  characterize 
all  such  translation  axioms  that  one  would  need  to  use  in  a  proof.  For  example,  we  need 
two  axiom  schemes  like  the  ones  given  above  for  translating  assertions  about  instances 
of  IntTriple  into  assertions  about  instances  of  IntPair. 

7.2  NOAL  Program  Verification 

In  this  section  we  describe  how  to  use  the  Hoare  logic  of  the  previous  section  to  verify 
NOAL  programs.  We  also  give  several  examples  of  program  verification. 

To  verify  a  NOAL  program,  one  first  gives  specifications  for  each  recursive  function 
definition  (see  Chapter  4)  and  shows  that  the  recursive  function  definitions  satisfy  their 
specifications.  Then  one  can  use  our  Hoare  logic  to  show  that,  if  the  formals  satisfy  the 
desired  precondition,  the  program  terminates  and  the  possible  results  satisfy  the  desired 
postcondition.  That  is,  given  a  program  whose  body  is  the  expression  E,  one  must  prove 
\-  P  {v  ^  E}  Q,  where  v  is  the  formal  result  identifier  from  the  program  specification, 
P  is  the  program’s  precondition,  and  Q  is  its  postcondition. 

Two  steps  are  required  to  verify  a  system  of  recursive  function  definitions.  First,  one 
shows  that  for  each  function  f,  h  Pre(f)  {y  4—  E)  Post(f)  follows  from  the  proof  rules, 
where  E  is  the  body  of  f ,  y  is  the  formal  result  identifier  from  the  specification  of  f, 
Pre(f)  is  the  precondition  from  the  specification  of  f,  and  Post(f)  is  its  postcondition. 
During  this  proof  one  can  use  the  axiom  schemes  [fcall-a]  and  [fcall-b],  which  implicitly 
assume  that  each  recursively  defined  function  meets  its  specification.  This  allows  one  to 
prove  the  partial  correctness  of  function  bodies  containing  recursive  calls.  The  second 
step  is  to  prove  that  each  function  terminates  whenever  it  is  called  with  arguments  that 
model  its  precondition.  This  step  is  necessary,  since  otherwise  one  could  implement  a 
recursive  function  specification  with  a  body  that  simply  called  itself  recursively.  (We  do 
not  provide  an  explicit  method  for  reasoning  about  termination.) 

As  a  simple  example  of  function  verification,  we  show  that  the  following  function 

fun  sumFirst(pl,p2: IntPair) :  Int  =  add(first (pi) .first (p2) ) 

implements  the  specification  sumFirst  of  Figure  1.4  on  page  15  (which  references  the 
specification  IPT).  Since  there  are  no  recursive  calls,  this  function  always  terminates.  So 
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it  suffices  to  show  using  our  Hoare  logic  that 

I-  true  {i  <—  add(first(pl)  .first (p2)) }  i  =  pi. first  4- p2. second 

We  find  it  eeisiest  to  start  with  the  formula  to  be  proved  as  a  goal  and  to  use  the 
rules  of  inference  to  generate  subgoals.  Since  the  body  of  sumFirst  consists  of  a  nested 
generic  invocation,  the  conclusion  must  follow  from  the  rule  [ginvoc-b].  So  we  rewrite 
the  body  of  sumFirst  as  follows: 

(fun  (i:Int,  j:Int)  add(i,j))  (first(pl),  first(p2)). 

(We  choose  the  identifiers  i  and  j  to  match  the  axiom  for  add.) 

The  rewritten  body  is  a  combination,  so  we  must  use  the  rule  [comb].  We  can  see 


from  the  rule  [comb]  that  we  have  as  subgoals  proving; 

b  true  {vl  <—  first  (pi)}  vl  =  pl.first  (7.10) 

I-  true  {v2  <—  f irst(p2)}  v2  =  p2. first  (7.11) 

vl  'Jliat  i  b  (vl  =  pl.first)  (i  =  pl.first)  (7.12) 

v2  T^int  j  b  {v2  =  p2.first)  =»•  (j  =  p2.first)  (7.13) 

b  i  =  pl.first  &  j  =  p2.first  {k  add(i,  j)}  k  =  pl.first  +  p2.first.  (7.14) 


The  first  two  subgoals  follow  from  the  instance  of  the  axiom  scheme  [ginvoc-a]  for 
first 

b  true  {i  +—  first (p)}  i  =  p.first  (7.15) 

and  the  inference  rule  [rename]. 

The  translation  axioms  for  Int  are  valid  because  if  7^  is  a  simulation  relation,  then 
T^int  is  the  identity  on  integers. 

To  prove  the  final  subgoal,  we  use  the  axiom  scheme  [ginvoc-a]  for  add: 

b  true  {add(i,  j)}  k  =  i -f  j  (7.16) 

and  the  rules  [conseq]  (used  twice)  and  [carry]. 

Since  all  the  hypotheses  of  the  [comb]  rule  hold,  the  desired  result  follows. 

Notice  that  our  proof  of  the  correctness  of  sumFirst  does  not  mention  the  type 
IntTriple.  This  is  what  we  mean  by  using  nominal  type  information  in  verification. 
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As  an  example  of  program  verification,  consider  the  specification  is2vaiting  given 
in  Figure  4.1  and  the  program 

waiting? (m, 2). 

The  following  lemma  verifies  that  this  program  is  correct.  The  proof  goes  into  more 
detail  than  the  previous  example. 

Lemma  7.2.1.  Suppose  that  H  true  {v2  ♦—  2}  v2  =  2  where  v2  has  nominal  type 

Int.  Suppose  further  that  for  all  identifiers  m,  vl,z  :  Mob  and  v2,i  :  Int,  the  following 

translation  axioms  are  valid: 

vl  TlMob  m  h  (2  €  z)  =  (2  €  vl)  =}►  (2  6  z)  =  (2  G  m)  (7.17) 

v2  Hint  il-v2  =  2  ^  i  =  2  (7.18) 

Then  h  true  {b  <—  waiting? (m, 2)}  b  =  (2  6  m). 

Proof:  By  the  inference  rule  [ginvoc-b],  it  suffices  to  show  that 

h  true  {b  ♦-  (fun  (m:Mob,  i:Int)  waiting? (m,i))  (m,2)}  b  =  (2  €  m).  (7.19) 

To  show  this,  we  use  the  rule  [comb]. 

Let  Ri  be  the  assertion  (2  G  m)  =  (2  G  vl),  where  b  :  Bool  and  vl  :  Mob.  Let  R2  be 
the  assertion  v2  =  2,  where  v2  :  Int. 

By  the  axiom  [ident]  we  have 

t-  true  {vl  m}  (2  G  vl)  =  (2  G  m).  (7.20) 

By  the  hypothesis,  we  have  h  true  {v2  2}  v2  =  2.  This  is  the  first  set  of  hypotheses 

for  the  [comb]  rule. 

Now  we  must  translate  the  assertions  (2  G  m)  =  (2  G  vl)  and  v2  =  2.  Since  m  is  a 
free  identifier  of  the  precondition  and  appears  free  in  the  first  assertion,  we  rename  it  to 
z.  The  second  hypothesis  of  this  lemma  h^ls  the  necessary  translation  axioms. 

By  the  axiom  scheme  [ginvoc-a]  and  the  specification  of  Mob,  we  have 

t-  true  (b  *—  waiting?(in,i) }  b  =  i  G  m.  (7-21) 


Since  (2  6  z)  =  (2  G  m)  &:  i  =  2  =>  true,  by  the  inference  rule  [conseq]  we  have 


I-  (2  e  z)  =  (2  G  a)  &:  i  =  2  {b  <—  waiting? (a, i)}  b  =  i  G  a.  (7.22) 

The  assertion  (2  G  z)  =  (2  G  a)  &  i  =  2  is  observable,  since  waiting?(z,2)  is  a 
characteristic  observation  for  (2  G  z),  (2  G  a)  is  similarly  observable,  and  the  rest  of  the 
assertion  can  be  observed  by  simple  combinations  of  the  operations  of  types  Bool  and 
Int.  So  by  the  inference  rule  [carry]  we  can  carry  the  precondition  into  the  postcondition 
and  obtain  as  our  postcondition: 

(2  G  z)  =  (2  G  n)  &  i  =  2&  b=  iGa.  (7.23) 

Now  we  use  the  axioms  about  equality  to  show  that 

(2  G  z)  =  (2  G  a)  &  i  =  2  &  b  =  i  G  a  =»  b  =  (2  G  z).  (7.24) 

So  by  a  final  application  of  [conseq]  we  have  the  desired  third  hypothesis  of  the  [comb] 
rule: 

h  (2  G  z)  =  (2  G  a)  &  i  =  2  {b  waiting? (a, i)}  b  =  (2  G  z),  (7.25) 

Since  we  have  shown  all  the  hypotheses  of  the  [comb]  rule,  we  can  conclude  that 

f-  true  {b  *—  waiting? (a, 2)}  b  =  (2  G  a).  (7.26) 

I 

Again,  the  above  proof  makes  no  mention  of  the  subtypes. 

To  show  how  our  logic  handles  explicit  use  of  inclusion  polymorphism,  we  will  show 
that 

h  true  {j  <—  sumFirst(Bake(IntPair,l,2)  ,  maJce(IntTriple,4,5,6))}  j  =  5. 

Since  this  expression  consists  of  a  nested  generic  invocation,  we  must  use  the  [ginvoc- 
b]  rule  to  rewrite  our  program  as  follows: 

(fun  (pl,p2:IntPair)  suaFirst(pl,p2)) 

(makeClntPair, 1 ,2) ,  make(IntTriple,4,5,6)) . 


We  now  must  use  the  [comb]  rule. 
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It  is  easy  (although  tedious)  to  show  that  the  first  set  of  hypotheses  of  the  [comb] 
rule  hold: 

t~  true  {vl  make (IntPair,  1,2)}  vl.first  =  1 

I-  true  {v2  ♦—  m2dce(IntTriple,4,5,6)}  v2.first  =  4, 

where  vl  :  IntPair  and  v2  :  IntTriple. 

We  take  as  translation  axioms: 

vl  '/^IntPair  pl  (vl.first  =  !)=>•  (pl.first  =  1)  (7.29) 

v2  T^intPair  p2  t"  (v2.first  =  4)  =»  (p2.first  =  4).  (7.30) 

We  can  show  the  final  hypothesis  of  the  [comb]  rule  using  the  fociom  scheme  [fcall-a] 
and  the  inference  rules  [conseq]  and  [carry].  The  axiom  for  sumFirst  is: 

h  true  {i  <—  s\imFirst(pl,p2)}  i  =  pl.first  +  p2. first.  (7.31) 

Using  the  rules  [conseq],  [carry],  and  the  trait  Int  we  can  conclude: 

h  pl.first  =  1  &p2. first  =  4  {i  <—  sumFirst (pl,p2)}  i  =  5.  (7.32) 

So  by  the  rule  [comb],  the  desired  result  follows. 

7.3  Soundness  of  Hoare-style  Verification  for  NOAL 

In  this  section  we  show  the  soundness  of  the  Hoare-style  symbolic  verification  technique 
for  NOAL  programs  described  in  the  previous  section. 

For  soundness  to  hold  we  must  have  simulation  relations  that  witness  the  referenced 
specification’s  presumed  subtype  relation  <.  It  is  not  enough  to  know  <  is  a  subtype 
relation,  because  we  need  to  ensure  that  the  result;  "^f  each  expression  can  be  simulated  at 
the  expression’s  nominal  type.  Furthermore,  our  translation  axioms  depend  on  simulation 
relations. 

We  also  need  to  assume  that  certain  assertions  are  observable  as  required  by  our 
Hoare  logic.  These  assumptions  ensure  that  if  a  precondition  holds  in  an  environment 
that  obeys  a  subtype  relation,  it  also  holds  in  nominal  environments  that  the  first  envi¬ 
ronment  simulates.  We  can  then  find  the  operation  or  function’s  effect  using  the  nominal 
environment. 


(7.27) 

(7.28) 
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The  following  lemma  is  the  essential  step  in  proving  the  soundness  theorem  for  our 
Hoare  logic.  It  says  that  if  some  Hoare-triple  is  provable,  and  one  has  an  algebra- 
environment  pair  that  models  the  precondition,  then  one  can  build  a  nominal  algebra- 
environment  pair  that  models  the  triple.  Soundness  follows  directly. 

The  lemma’s  proof  is  by  induction  on  the  length  of  proof  in  our  Hoare  logic.  The 
interesting  cases  are  the  axiom  schemes  [ginvoca-a],  and  the  rules  [comb],  [conseq]  and 
[carry]  since  these  are  the  rules  where  there  is  a  substantial  difference  from  standard 
Hoare  logics.  In  the  [ginvoc-a]  rule  one  builds  a  nominal  environment  that  the  given 
environment  simulates.  Because  the  precondition  is  observable,  the  nominal  environment 
also  models  the  precondition.  Since  we  know  what  operation  is  executed  by  the  generic 
invocation  in  the  nominal  environment,  we  can  use  the  type  specification  to  show  that  the 
expression  terminates  and  the  postcondition  holds  for  the  nominal  environment.  In  the 
rule  [comb]  we  use  the  semantics  of  the  translation  axioms  to  build  the  required  nominal 
environments.  In  the  proofs  of  the  rules  [conseq]  and  [carry]  we  use  the  observability  of 
the  assertions  involved  to  show  that  implication  and  conjunction  mean  what  we  expect. 

Lemma  7.3.1.  Let  SPEC  be  a  specification.  Let  <  be  the  presumed  subtype  relation 
of  SPEC.  Let  F  be  a  system  of  mutually  recursive  NOAL  functions.  Let  C  and  A  be 
SPFC-algebras. 

Suppose  that  <  is  a  reflexive  and  transitive  subtype  relation  on  the  types  of  SPEC 
with  respect  to  type-safe  NOAL  programs,  <  is  safe  with  respect  to  NomSig,  each  func- 
tion  f,  e  F  satisfies  its  specification,  the  only  type  related  to  each  visible  type  T  by  <  is 
T  itself,  and  7^  is  a  simulation  relation  between  C  and  A  for  NomSig  and  <  such  that  % 
witnesses  <. 

Then  for  all  Hoare-triples  for  SPEC.,  P  {y  *—  E)  Q.,  such  that  the  free  function 
identifiers  of  E  are  the  f,-,  for  all  sets  X  of  typed  identifiers  such  that  X  contains  all 
the  free  identifiers  of  P  and  E  and  Q  except  y,  the  following  condition  holds  whenever 
P  {y  E}  Q’.  for  all  environments  rjc  €  ENV{X ,C)  that  are  proper  and  obey 
<,  for  all  nominal  environments  t^a  €  ENV{X.,A),  if  rjc  Tt  t^a  and  {C,r}c)  [=  P,  then 
Wa  \P\  =  true.,  and  for  all  possible  results  r  €  A4|F]{A,  r  ^  ±,  and  (A,  r/x[’'/y])  |=  Q- 

Proof:  (by  induction  on  the  length  of  proof  in  the  Hoare  logic.) 
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Let  Z  be  the  set  of  typed  function  identifiers  f,-.  To  find  the  set  of  possible  results  of 
a  NOAL  expression  with  free  function  identifiers  from  Z  one  needs  an  environment  that 
is  defined  on  the  function  identifiers  in  Z.  However,  since  there  is  only  one  denotation  for 
a  recursively  defined  NOAL  function  in  a  given  algebra,  there  is  only  one  way  to  expand 
a  given  environment  to  one  that  maps  the  function  identifiers  in  Z  to  their  denotations 
in  that  environment’s  range.  Furthermore,  if  then  the  expansions  of  t/c  and 

are  also  related  by  V,,  by  Lemma  6.2.2.  So  to  avoid  notational  complications,  we  do  not 
mention  this  expansion  below. 

We  shall  often  use  the  following  property.  If  and  t)c  is  proper,  then  is  also 

proper,  since  72.  is  bistrict. 

For  the  basis,  we  show  that  the  result  holds  for  each  of  the  axiom  schemes. 

•  Suppose  the  proof  consists  of  an  instance  of  the  axiom  scheme  [ident] 

1-  true  {v  4—  x}  Af[v/z]  =  Af[x/z] 

for  some  identifiers  x,  v,  and  z  of  some  type  T.  Let  A  be  a  set  of  typed  identifiers 
that  includes  x  ;  T  but  not  v  :  T.  Let  rjc  €  ENV {X,C)  be  proper  and  obey  <.  Let 
ija  €  ENV(X,A)  be  a  nominal  environment  such  that  rjc  'E-Va-  It  is  trivial  that 
{C,T]c)  H  true  and  that  ^[truej  =  true.  By  definition,  Af  [x](A,t//i)  =  {t/4(x)}. 
Since  T)c  is  proper  t/^(x)  is  also  proper.  Finally,  it  is  trivial  that  [A,  |= 

M[v/z]  =  M[x/z]. 

•  Suppose  the  proof  consists  of  an  instance  of  the  axiom  scheme  [bot] 

h  false  {v  <—  bottomCT]}  true. 

Then  the  result  follows  trivially,  since  no  environment  can  model  the  precondition 
“false.” 

•  Suppose  the  proof  consists  of  an  instance  of  the  axiom  scheme  [ngop] 

h  true  {v  *—  T()}  v  =  T 


where  v  has  nominal  type  TClass.  (This  return  type  is  uniquely  determined  by 
T,  because  of  the  restrictions  of  our  specification  language.)  Let  A  be  a  set  of 
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typed  identifiers  that  does  not  contain  v  :  TClass.  Let  tjc  €  ENV{X ,C)  be 
proper  and  obey  <.  Let  E  ENV(X,A)  be  a  nominal  environment  such  that 
‘He  'E.  7] A.  It  is  trivial  that  (C,  tjc)  |=  true  and  that  ^[true]  =  true.  By  definition 
of  when  an  algebra  satisfies  a  specification  (see  Chapter  2),  the  only  possible  result 
of  Af  [T()|(i4,  •qA)  is  the  proper  object  of  type  TClass  that  is  the  result  of  the  trait 
function  “T,”  call  it  Ta.  So  (>1,?7^[T^/v])  ^  v  =  T. 

•  Suppose  the  proof  consists  of  an  instance  of  the  axiom  scheme  [ginvoc-a] 

1“  Pie(gg^T)  {y  ^  Post(gg^T.) 

where  the  x  :  S  are  the  formal  arguments  from  the  specification  of  the  operation 
g  with  nominal  signature  S  — +  T  and  y  :  T  is  the  formal  result  identifier  from  that 
specification  of  g. 

By  the  restrictions  of  our  specification  language,  the  types  of  the  formal  arguments 
uniquely  determine  the  type  of  the  formal  result  and  hence  the  precondition  and 
postcondition.  That  is,  the  specification  SPEC  only  contains  one  operation  spec¬ 
ification  for  g  with  this  nominal  signature.  This  means  that  SPEC-a\gehta.s  have 
an  operation  named  SS~*T^  cannot  have  operations  named  for  t  ^  T. 

Let  X  contain  the  formals  x,-  but  not  y  :  T.  Let  qc  €  ENV{X  ,C)  be  proper 
and  obey  <.  Let  qA  €  ENV{X ,  A)  be  a  nominal  environment  such  that  qc  TZqA- 
Suppose  that  {C,qc)  1=  Pre(gg_T)-  Since  by  hypothesis  this  precondition  is  ob¬ 
servable,  {A,qA)  Pre(gg_j)  by  Lemma  5.2.4.  Since  qA  is  a  nominal  environment, 
by  Lemma  4.4.3 

^lPre(gs_*T)l  =  (7.33) 

Since  qA  is  a  nominal  environment, 

A4[g(x)J(/l,?7A)  =  >igg^.j(»7(x)).  (7.34) 

By  definition  of  when  an  operation  satisfies  its  specification,  for  all  possible  results 
r  €  Ag^^^{q{x)),  r  ^  ±  and  J7>i[r/y][Post(gg^T)l  = 

Suppose  the  proof  consists  of  an  instance  of  the  axiom  scheme  [fcall-a] 


I-  Pre(f)  {y  <—  f  (x)}  Post(f) 
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where  the  x  :  S  are  the  formal  arguments  from  the  specification  of  the  NOAL 
function  f  with  nominal  signature  S  — ^  T  and  where  y  :  T  is  the  formal  result 
identifier  from  this  specification.  Let  X  contain  the  formals  Xj  but  not  y  :  T.  Let 
Tjc  G  ENV{X ,C)  be  proper  and  obey  <.  Let  t/x  G  ENV{X,A)  be  a  nominal 
environment  such  that  i/c  72.  t;. 

Suppose  that  {C,rfc)  Pre(f).  Since  by  hypothesis  the  precondition  is  observable, 
{A,7]a)  1=  Pre(f)  by  Lenuna  5.2.4.  So  by  Lemma  4.4.3,  ^|Pre(f)]  =  true. 

By  hypothesis,  f  satisfies  its  specification.  So  by  definition  of  when  a  NOAL  func¬ 
tion  satisfies  its  specification,  for  all  possible  results  r  G  (x)](A,  r  ^  ± 
and  {A,T]A[r/y])  Post(f). 

For  the  inductive  step,  we  suppose  that  the  result  holds  for  aU  proofs  of  length  less 
than  n.  Suppose  that  we  are  given  a  proof  of  length  n  >  1.  The  last  step  of  the  proof  must 
be  either  an  axiom  or  the  conclusion  of  an  inference  rule  in  our  proof  system.  The  axioms 
were  covered  above,  so  it  remains  to  deal  with  each  of  the  rules  of  inference.  Since  all  the 
conclusions  of  the  rules  of  inference  have  a  similar  form  (l-P{y<— JS}Q)we  establish 
some  conventions  here  instead  of  repeating  them  in  what  follows.  Let  the  nominal  type 
of  the  expression  (E)  be  T.  Let  be  a  set  of  typed  identifiers  that  contains  all  the  free 
identifiers  of  P,  E  and  Q  except  the  result  identifier  y  :  T.  Let  ijc  G  ENV{X  ,C)  be 
proper  and  obey  <.  Let  t}a  G  ENV{X,A)  be  a  nominal  environment  such  that  J/c 

•  Suppose  the  last  step  is  the  conclusion  of  the  rule  [ginvoc-b]: 

\-P{y*-S(E)}Q. 

The  hypothesis  of  this  rule 

H  P  {y  ^  (fun  (£:  S)  g(x))  (P)}  Q 
must  therefore  appear  in  an  earlier  step.  Since  by  definition  of  NOAL, 

A4[g(P)I(C7,7,c)  =  Af[(fun  (x:S)  g(x))  (£)]  ](C,r)c  (7.35) 


the  result  follows. 


Suppose  the  last  step  is  the  conclusion  of  the  rule  [fcall-b].  Then  the  claim  follows 
as  for  the  rule  [ginvoc-b]. 

Suppose  the  last  step  is  the  conclusion  of  the  rule  [comb]: 

t-P{y^(fun  (£:S)  g(£))  . .  ,EJ}  Q. 

Suppose  (C,  -qc)  f=  P- 

For  each  i  from  1  to  n,  there  is  some  earlier  step  in  the  proof  of  the  form  h  P  {vj  +— 
Ei}  Hi.  Let  r,-  G  M\Ei\{A,qA)  be  a  possible  result  of  the  argument  expression  Ei, 
whose  nominal  type  is  <t,-.  By  the  inductive  hypothesis, 

fiJ[P]  =  true,  (7.36) 

r,-  ^  ±,  and  (i4,j;^[r,7v,])  [=  Ri.  By  Lemma  6.2.2  and  Lemma  6.2.1,  each  g,-  6 
M[Ei](C,qc)  is  such  that  qi  'R.ri. 

There  must  also  be  some  step  in  the  proof  of  the  form 

v<7ls,x.H/2..[2/jq=>p;  (7.37) 

To  use  this  translation  axiom  we  show  how  suitable  versions  of  the  above  envi¬ 
ronments  satisfy  the  conditions  for  a  translation  axiom.  We  define  the  following 
environments: 

Vic  lc[vc{i)/^  (7.38) 

Va  -  (7.39) 

By  construction,  q'c  By  the  above,  for  each  i,  (C*, r/cfg./vj])  ^  i2j[z/£]  and 

the  environment  t/cfe/vi]  is  proper.  Since  <  is  reflexive  and  transitive,  <  is  safe 
with  respect  to  NomSig,  and  Ei  is  type-safe,  the  environment  »/c[9i/V|]  obeys  <  by 
Lemma  3.6.5.  So  by  the  translation  axiom  quoted  in  the  proof,  (y4,»/^[r,/xj])  \=  R'i- 

By  definition  of  NOAL,  r  is  a  possible  result  of  the  entire  combination  expression 
only  if  r  €  M.[Eol{A,q'yi^[f/x\).  There  must  be  a  step  in  the  proof  of  the  form 


\-R[k---kR'„{y'^Eo}  g[z/£]. 


(7.40) 
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where  y'  is  y[z/5c].  By  construction. 

(7.41) 

Since  7c ^  Lemma  5.2.3, 

(7.42) 

By  the  inductive  hypothesis, 

r  ^  ± 

(7.43) 

and  (>1,  (7^[^/x])[r/y'])  |=  Q[z/x].  So  by  undoing  the  renamings, 

we  have 

(/l,(74[r/z])[r/y])  |=  Q. 

(7.44) 

Since  the  z  are  fresh, 

(»7>l[r/y])[f7z]  =  (7^[r/z])[r/y], 

(7.45) 

and  therefore 

{MriA[r/Y])[rm)\=Q^ 

(7.46) 

Since  the  z  do  not  occur  free  in  Q,  by  Lemma  5.2.6, 

{A,r)A[rly])  1=  Q. 

(7.47) 

Suppose  the  last  step  is  the  conclusion  of  the  rule  [if]: 

h  P  {y  <—  if  E\  then  Ej  else  Ez  fi}  Q 

Suppose  (C,7c)  h  P- 

There  must  be  an  earlier  step  in  the  proof  of  the  form  t-  P  {v  <— 

Pi}  true.  So  by 

the  inductive  hypothesis, 

Wa\P]  =  true. 

(7.48) 

and  for  all  ri  €  rj  ^  ±.  Since  Ei  has  nominal  type  Bool  and  no 

other  types  are  related  to  Bool  by  <,  each  ri  must  have  type  Bool. 

There  must  be  an  earlier  step  in  the  proof  of  the  form  \-  PSzRi  {v  ♦—  Ei}  v  =  true. 
By  the  inductive  hypothesis,  if  {C,t}c)  f=  P  &:  Ri,  then  M\Ei\{A,'qA)  =  {true}. 
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Furthermore,  there  must  be  an  earlier  step  in  the  proof  of  the  form  h  P&cRi  {y  ♦— 
E2}  Q.  So  if  {C,T)c)  1=  P  &:  Pi,  then  for  all  rj  G  Ai[F2l(A,  t/^),  r2  ^  ±  and 
{AvA[r2/y])  h  c?. 

There  must  also  be  earlier  steps  in  the  proof  of  the  form  h  P  &  Pj  {v  Pi }  v  = 
false  and  H  P  &  P2  {v  ^  P3}  Q,  As  above,  if  {C,r}c)  ^  P  &  P2,  then  for  all 
rs  G  jV1IP3](A,77^),  1.  and  (A, J^^lrg/y])  [=  Q. 

There  must  also  be  earlier  steps  in  the  proof  of  the  form  t-  P  &;  P3  {P2}  Q  ^‘•nd 
h  P  &:  P3  {P3}  Q.  So  if  (C',7jc)  P  Rz,  then  for  all  r^z  G  MlE2\{A,riA)  U 
M[E3}{A,t}a),  r2z  7^  -L  and  (A,?;^{r23/y])  h  Q. 

Finally,  there  must  be  an  earlier  step  in  the  proof  of  the  form  (P1IP2IP3)  =  true. 
Since  {C,T}c)  |=  P,  it  follows  that  for  some  i  from  1  to  3,  {C,Tfc)  |=  P  &  Pj,  So  by 
the  inductive  hypothesis,  rUiP  PiJ  =  true.  Let  r  be  a  possible  result  of  the  if 
expression  in  (A,  j/a);  that  is  suppose  that 

AdlP2l(A,i?>i)  if  ri  =  true 

rG  y  -  MIEzMA.tia)  if  ri=  false  (7.49) 

r,€vV«IEil(.4,f,^)  {_L}  otherwise 

Then  r  ^  ±,  because  by  the  above,  the  only  possible  results  of  Pi  are  either 
true  or  false.  Furthermore,  for  each  i  such  that  ^[P  &  P^J  =  true,  r  ^  ±  and 
{A,i]A[r/y])  1=  Q  by  the  above. 

Suppose  the  last  step  is  the  conclusion  of  the  rule  [erratic]: 

Suppose  {C,Tjc)  P.  There  must  be  earlier  steps  in  the  proof  of  the  form  h 
P  {y  Pi)  ^  and  I-  P  {y  P2}  Q.  Each  possible  result  of  Pi  []  P2  is  a  possible 
result  of  either  Pi  or  P2.  By  the  inductive  hypothesis,  >fj[P]  =  true,  and  for  each 
possible  result  r  of  either  E\  or  P2  in  {A,j]a),  t  ^  ±  and  (A,  T/^[r/y])  ^  Q. 

Suppose  the  last  step  is  the  conclusion  of  the  rule  [angelic].  Then  the  result  follows 
as  for  the  rule  [erratic],  since  each  possible  result  of  Pi  y  P2  is  a  possible  result  of 
either  Pi  or  P2. 
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•  Suppose  the  last  step  is  the  conclusion  of  the  rule  [isDef]: 

h  P  {y  4—  isDef?(P)}  y  =  true 

Suppose  {C,T]c)  H  f*-  There  must  be  an  earlier  step  in  the  proof  of  the  form 
\-  P  {y  *—  E}  true.  By  the  inductive  hypothesis,  =  true  and  for  all  r  6 

M\E\{A,'qA)i  r  ^  X.  Therefore,  by  definition  of  NOAL,  A^[isDef?(P)](A, = 
{true}.  Furthermore,  since  true  is  the  only  possible  result  it  only  remains  to  show 
that  {A,7]A[true/y])  [=  y  =  true,  which  is  trivially  true. 

•  Suppose  the  last  step  is  the  conclusion  of  the  rule  [conseq]: 

\-P{y^E}Q 

Suppose  iC,T}c)  H  Since  P  is  observable,  by  Lemma  5.2.4  and  Lemma  4.4.3, 
^1^1  =  true. 

There  must  be  a  step  in  the  proof  of  the  form  h  P  =>•  Pi.  In  general.  Pi  and  Qi 
may  have  more  free  identifiers  than  P  and  Q.  For  example,  if  i  has  nominal  type 
integer,  then  the  formula  “true  =>•1  =  1”  and  its  converse  are  both  valid.  Let  z  :  S 
be  a  tuple  of  all  the  free  identifiers  of  Pi  and  Qi  except  for  the  result  identifier  y  :  T 
that  are  not  in  X  (i.e.,  that  are  not  in  the  domain  of  ijc)-  Let  q  &  C§  he  a.  tuple  of 
proper  elements.  Since  <  is  reflexive,  rjcW/^  obeys  <.  Since  7Z  witnesses  <,  there 
are  r  G  Ag  such  that 

rjclq/^  nA[r/z\.  (7.50) 

Notice  that  T/^ifr/z]  is  nominal.  Since  P  Pi  is  valid  in  all  nominal  environments, 

^A[rlz\[P  =>  PiJ  =  true.  (7.51) 

So  by  definition, 

(C,,c[9721)  (T.52) 

Therefore,  by  Theorem  5.2.5, 


{C,rjc[qlA)  N  A. 


(7.53) 
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There  must  also  be  a  step  in  the  proof  of  the  form  I-  Pi  {y  E}  Qi.  By  the 
inductive  hypothesis  and  the  above, 

‘nA[rli]lPi\  =  true  '  (7-54) 

and  for  all  r'  6  M{E\{A,riA[rli\)y  P  ■=^  X,  and  {A,{r]A[rl^)[r'ly])  |=  Q^,. 

Finally,  there  must  be  an  earlier  step  in  the  proof  of  the  form  H  Qi  Q-  Since 
E  is  type-safe,  <  is  reflexive  and  transitive,  and  <  is  safe  with  respect  to  NomSig, 
by  Lemma  3.6.5  (»7>i[r/z])[r'/y]  obeys  <.  Since  Qi  and  Q  are  observable,  by  Theo¬ 
rem  5.2.5 

(A.(,.,|fVzl)lr7yl)l=<?  (7.55) 

Since  the  z;  are  not  free  in  Q,  by  Lemma  5.2.6, 

{AMr'M)\=Q-  (7.56) 

•  Suppose  the  last  step  is  the  conclusion  of  the  rule  [carry]: 

h  P  {yi-E}  PkQ 

Suppose  (C,‘qc)  1=  P-  There  must  be  an  eeurlier  step  in  the  proof  of  the  form 
P  {y  *—  E}  Q.  By  the  inductive  hypothesis,  ^[PJ  =  true  aind  for  all  r  6 
M[E\{A,r]A)-,  r^l.  and 

M,»7/il^/y])  f=  Q-  (7.57) 

Since  nA[P\  =  true  and  tja  is  nominal,  (/4,  N  P-  Since  <  is  reflexive  and 
transitive  and  <  is  safe  with  respect  to  NomSig,  by  Lemma  3.6.5,  »?>i[r/y]  obeys 
<.  Since  y  is  not  free  in  P,  <  is  a  subtype  relation,  J7/i[r/y]  obeys  <  and  P  is 
observable,  by  Lemma  5.2.7, 


{A,r)A[r/y])  h  P-  (7.58) 

Since  P  Sz  Q  \s  logically  equivalent  to  ->{P  =»  -iQ),  P  and  Q  are  observable,  and 
r/yi[r/y]  is  proper  and  obeys  <,  by  Theorem  5.2.2  and  Theorem  5.2.5, 


('^.Ijjlr/y))  PkQ. 


(7,59) 
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•  Suppose  the  leist  step  is  the  conclusion  of  the  rule  [rename]: 

hP{y*-E}Q 

Since  the  identifiers  z  are  fresh,  the  possible  results  of  £^[z/x]  in  rjclvci^)/^  a-re 
the  same  as  the  possible  results  of  E  in  (C^rjc)- 


■ 

The  following  theorem  is  the  soundness  theorem  for  our  Hoare  logic. 

Theorem  7.3.2.  Let  SPEC  be  a  specification.  Let  <  be  the  presumed  subtype  relation 
of  SPEC.  Let  NomSig  be  the  nominal  signature  map  of  SPEC.  Let  F  be  a  system  of 
mutually  recursive  NOAL  functions. 

Suppose  that  <  is  reflexive  and  transitive,  <  is  safe  with  respect  to  NomSig,  the 
only  type  related  to  each  visible  type  T  by  <  is  T  itself,  each  function  f,  €  F  satisfies 
its  specification,  and  that  for  every  SPFC-algebra  C  there  is  some  SPFC-algebra  A  and 
some  simulation  relation  Tl  between  C  and  A  for  NomSig  and  <  such  that  %  witnesses 
<.  Then  for  all  Hoare-triples  P  {y  *—  E}  Q  (or  SPEC,  if  the  free  function  identifiers  of 
E  are  the  f,  in  F  and  h  P  {y  ^  E}  Q,  then  SPEC  \=^  P  {y  *—  E}  Q. 

Proof:  Let  P  {y  +—  F}  Q  be  a  Hoare-triple,  where  X  is  the  set  of  free  identifiers 
of  P  and  the  nominal  type  of  E  is  some  type  T.  Let  C  be  a  5PFC-algebra.  Let  gc  G 
ENV{X ,C)  be  such  that  rjc  is  proper  and  obeys  <.  Suppose  that  (C,  t/c)  ^  P. 

By  hypothesis,  there  is  some  SPFC-algebra  A  and  some  simulation  relation  P,  between 
C  and  A  for  NomSig  and  <  such  that  7?.  witnesses  <.  Using  this  TZ  we  can  build  a  nominal 
environment  7/^  6  ENV{X,A)  such  that  ijc Va-  By  Lemma  7.3.1,  ^|Pl  =  true, 
and  for  all  r  6  AilE]{A,T]A),  r  ^  ±  and  (A, r/^fr/yj)  [=  Q.  Since  tja  is  nominal, 
{A,t]a)  ^  P.  Since  TZ  is  a.  simulation  relation,  by  Lemma  6.2.2  and  Lemma  6.2.1,  for 
each  q  G  M.\E\{C ,Tqc) i  there  is  some  r'  G  M\E\{A,t)a)  such  that  qlZ-^r' .  So  q  is  proper, 
since  7^  is  bistrict.  Since  T/c[9/y]  Ly  Lemma  5.2.3,  (C,  T^ci^/y])  [=  Q-  * 

In  the  above  theorem,  we  assumed  that  each  recursively  defined  function  appearing  in 
a  program  meets  its  specification.  Since  our  technique  for  proving  the  partial  correctness 
of  such  functions  is  standard,  we  will  not  show  formally  that  it  is  sound. 
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The  following  corollary  says  that  our  technique  for  the  verification  of  programs  is 
sound.  This  is  not  a  trivial  consequence  of  the  soundness  theorem  because  the  semantics 
of  our  specifications  require  that  each  possible  result  be  an  instance  of  a  subtype  of  the 
program  specification’s  nominal  return  type.  So  in  the  following  corollary  we  combine  the 
soundness  theorem  with  Lemma  3.6.5,  which  says  that  the  possible  results  of  a  type-safe 
NOAL  expression  must  be  instances  of  subtypes  of  the  expression’s  nominal  type.  This 
connection  to  the  type  system  of  NOAL  is  explored  further  in  the  next  section. 

Corollary  7.3.3.  Let  p  be  a  program  specification,  with  referenced  specification  SPEC, 
precondition  R  and  post  :ondition  Q  and  nominal  result  type  S.  Let  <  be  the  presumed 
subtype  relation  of  SPEC.  Let  NomSig  be  the  nominal  signature  map  of  SPEC.  Let 
P  =  F\  E  he  a.  NOAL  program  with  nominal  type  S,  where  F  is  a  system  of  mutually 
recursive  NOAL  functions,  and  F  is  a  NOAL  expression. 

Suppose  that  <  is  reflexive  and  transitive,  <  is  safe  with  respect  to  NomSig,  the 
only  type  related  to  each  visible  type  T  by  <  is  T  itself,  each  function  f,  E  F  satisfies 
its  specification,  and  that  for  every  5PFC-algebra  C  there  is  some  SPEC-algehra  A  and 
some  simulation  relation  7^  between  C  and  A  for  NomSig  and  <  such  that  7J.  witnesses 
<.  If  f-  i?  {y  ♦—  E}  Q,  then  P  satisfies  the  specification  p. 

Proof:  By  the  previous  theorem,  SPEC  ^  i?  {y  <—  E}  Q.  Since  E  has  nominal  type 
S,  by  Lemma  3.6.5,  each  possible  result  of  E  has  some  type  tr  <  S.  So  by  definition,  P 
satisfies  the  specification  p.  I 

7.4  How  a  Type  System  can  Aid  Verification 

In  this  section  we  discuss  how  type  checking  can  be  used  to  aid  program  verification. 
7.4.1  Obedience  in  NOAL 

For  soundness  of  our  Hoare-style  verification  technique  for  NOAL,  we  must  ensure  that 
the  possible  results  of  each  expression  are  instances  of  a  subtype  of  the  expression’s 
nominal  type.  We  cal!  this  property  obedience.  Fundamentally,  obedience  is  necessary 
because  our  function  specifications  require  that  the  arguments  and  results  of  a  function 
obey  a  subtype  relation.  Obedience  also  ensures  that  one’s  reasoning  about  assertions 
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using  standard  techniques  such  as  the  proof  by  contradiction  is  sound,  as  we  showed  in 
Chapter  5.  The  soundness  proof  for  our  Hoare  logic  requires  obedience  to  a  subtype 
relation  for  the  same  reason. 

Instead  of  checking  obedience  with  our  Hoare  logic,  we  separate  type  checking  from 
the  rest  of  the  verification  problem.  Separating  type  checking  from  our  Hoare  logic 
allows  the  logic  to  be  simpler  than  it  would  be  otherwise.  Furthermore,  this  separation 
also  allows  us  to  use  a  computer  to  check  mechanically  whether  our  program  is  type-safe, 
removing  part  of  the  burden  of  program  verification  from  humans. 

The  NOAL  type  system  can  ensure  obedience  of  type-safe  expressions  over  a  specifi¬ 
cation  SPEC  if  the  following  conditions  are  met. 

•  The  specification’s  presumed  subtype  relation  must  be  reflexive. 

•  The  specification’s  presumed  subtype  relation  must  be  transitive. 

•  The  presumed  subtype  relation  must  be  safe  with  respect  to  the  specification’s 
nominal  signature  map. 

These  reasons  for  these  conditions  are  explained  in  Section  3.6. 

In  addition,  the  above  conditions  are  plausible  and  intuitive.  Unless  <  is  reflexive, 
nominal  environments  will  not  be  obedient,  making  our  reasoning  based  on  nominal 
environments  counterintuitive.  Transitive  relations  are  also  more  compactly  described 
than  nontransitive  ones,  because  one  can  just  describe  a  basis  for  the  relation  and  take 
the  transitive  closure.  Finally,  unless  <  is  safe,  a  “subtype”  may  not  have  all  the  instance 
operations  of  its  supertypes,  and  so  its  instances  could  not  be  used  everywhere  that 
instances  of  the  supertype  could  be  used. 

7.4.2  Verification  in  Trellis/Owl 

It  is  easiest  to  use  our  Hoare-style  verification  techniques  in  a  statically  typed  object- 
oriented  programming  language,  because  a  properly  designed  type  system  can  do  some 
of  the  verification  work  automatically,  as  in  NOAL.  One  such  language  is  Trellis/Owl 
[SCB*86],  whose  type  system  was  the  inspiration  for  the  NOAL  type  system.  Like 
NOAL,  Trellis/Owl  type  system  is  based  on  nominal  signatures  and  a  presumed  subtype 
relation. 
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Trellis/Owl  limits  presumed  subtype  relations  to  be  partial  orders,  that  is  reflexive, 
transitive,  and  antisymmetric  relations  on  types.  Although  reflexive  and  transitive  rela¬ 
tions  are  necessary  for  type-checking  and  verification,  antisymmetry  is  not.  Trellis/Owl 
requires  that  a  presur.ied  subtype  relation  be  antisymmetric,  because  the  implementa¬ 
tion  of  each  presumed  subtype  is  also  a  subclass,  and  cyclic  inheritance  relationships  are 
nonsensical.  However,  symmetric  subtype  relationships  are  useful.  For  example,  consider 
types  HashTable  and  BTree.  We  can  specify  these  types  so  instances  of  these  types  obey 
a  common  protocol  for  inserting  and  finding  elements  and  so  that  each  is  a  subtype  of 
the  other,  although  they  can  have  different  class  operations. 

The  Trellis/Owl  type  system  supports  program  verification  by  ensuring  obedience 
to  the  presumed  subtype  relation.  As  in  NOAL,  it  ensures  this  by  requiring  that  the 
presumed  subtype  relation  is  safe,  reflexive  and  transitive.  The  presumed  subtype  rela¬ 
tion  of  a  Trellis/Owl  program  is  declared,  so  that  if  the  presumed  subtype  relation  is  a 
subtype  relation  (in  our  sense),  then  our  style  of  reasoning  should  be  useful  for  program 
verification  in  Trellis/Owl. 

7.4.3  Verification  in  Emerald 

Unlike  Trellis/Owl  the  designers  of  Emerald  [BHJL86]  have  made  the  mistake  of  inferring 
subtype  relationships  for  abstract  types.  Unfortunately,  it  is  easy  to  specify  types  so  that 
the  binary  relation  that  Emerald  infers  is  not  a  subtype  relation  in  our  sense.  Therefore 
to  ensure  that  every  environment  obeys  a  subtype  relation  in  an  Emerald  program,  one 
has  to  duplicate  work  that  the  type  checker  could  have  done. 

7.4.4  Verification  in  Smalltalk-80 

Many  popular  languages,  such  as  Smalltalk-80  [GRS3],  are  not  statically  type-checked  but 
are  type-checked  dynamically.  In  Smalltalk-80,  type  information  is  not  checked  during 
assignments,  but  only  on  generic  invocation.  To  support  data  abstraction,  Smalltalk-80 
ensures  that  each  object  is  manipulated  only  by  the  instance  operations  defined  by  its 
class  (including  those  inherited  from  superclasses).  Therefore,  when  an  instance  operation 
named  g  is  invoked  on  an  object  the  class  that  implements  q  must  define  operation 
g;  if  it  does  not,  an  error  occurs  and  is  reported  to  the  user.  Type  information  about 
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objects  is  also  available  to  Smalltalk-80  programs  during  execution. 

To  use  our  Hoare-style  reasoning  techniques  on  a  Smalltalk-80  program,  we  need  a 
notion  of  nominal  type  and  some  way  to  ensure  obedience  to  a  subtype  relation. 

To  supply  Smalltalk-80  programs  with  a  notion  of  nominal  type,  one  can  annotate 
one’s  programs  with  this  information.  The  Smalltalk-80  programs  in  Goldberg  and  Rob¬ 
son’s  book  [GR83]  already  follow  a  convention  of  putting  type  information  into  variable 
names  to  aid  understanding. 

There  are  two  ways  to  force  expressions  to  obey  a  subtype  relation:  dynamic  or  static 
checking.  Notice  that  we  cannot  rely  on  the  dynamic  type-checking  of  Smalltalk-80  to 
ensure  obedience,  because  Smalltalk-80  only  checks  that  an  instance  operation  invoked 
on  an  object  q  is  defined  by  q's  class. 

Dynamic  checking  could  use  the  type  information  available  at  run-time  in  Smalltalk- 
80  programs.  One  would  place  code  in  all  operations  to  check  that  all  the  operation’s 
arguments  have  a  type  that  is  a  subtype  of  their  nominal  type.  (Smalltalk-80  itself  checks 
the  first  or  “controlling”  argument,  so  no  checking  on  the  first  argument  is  needed.)  We 
say  that  a  Smalltalk-80  program  with  such  dynamic  type  checks  is  obedient  if  these 
checks  never  detect  an  instance  of  some  type  other  than  a  subtype.  Of  course,  there  is 
no  general  algorithm  for  deciding  when  a  Smalltalk-80  program  is  obedient. 

Another  way  to  ensure  obedience  would  be  to  do  static  type-checking  using  the  nom¬ 
inal  type  information  added  to  programs  cis  annotations.  It  should  be  easy  to  adapt  the 
NOAL  type  system  to  Smalltalk-80,  which  would  allow  us  to  do  some  type  checking  by 
hand,  or  to  write  a  tool  that  used  program  annotations  to  do  static  type  checking. 

In  reasoning  about  Smalltalk-SO  programs,  it  is  important  to  define  satisfaction  of 
specifications  and  subtype  relations  with  respect  to  a  set  of  obedient  programs.  Consider 
what  happens  if  we  take  as  our  set  of  observations  the  denotations  of  all  Smalltalk-80 
programs.  In  general,  operations  can  be  applied  to  expressions  regardless  of  their  “type.” 
As  we  noted,  this  may  result  in  an  “obedience”  error.  Consider  the  program 

aPair  third 

(which  is  the  equivalent  of  the  NOAL  expression  third(aPair)).  Suppose  aPair  denotes 
an  instance  of  IntPair.  Then  the  result  of  the  above  program  is  an  obedience  error, 
which  could  not  happen  in  an  environment  where  aPair  denotes  an  IntTriple.  So  the 
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observation  defined  by  this  program  would  be  able  to  distinguish  triples  from  pairs.  With 
type  annotations,  we  caji  decide  what  environments  obey  a  subtype  relation  and  we  can 
use  obedient  programs  to  describe  observations.  If  aPair  has  nominal  type  IntPair,  then 
the  above  program  would  not  be  obedient.  Therefore  IntTriple  would  be  a  subtype 
of  IntPair  with  respect  to  the  set  of  obedient  programs  but  not  with  respect  to  all 
Smalltalk-80  programs. 

7.5  Observable  Assertions  and  Reasoning 

In  this  section  we  discuss  the  role  that  observable  assertions  play  in  our  techniques  for 
specification  and  verification. 

In  Chapter  5  we  showed  that  we  can  reason  about  environments  that  obey  a  subtype 
relation  using  observable  assertions  and  standard  rules  from  logic.  Furthermore,  we 
showed  that  if  Q  is  an  observable  assertion,  then  an  environment  that  obeys  a  subtype 
relation  models  Q  if  and  only  if  there  is  no  way  to  observe  that  Q  does  not  hold.  So 
the  assumptions  that  assertions  are  observable  and  that  environments  obey  a  subtype 
relation  are  sufficient  to  ensure  that  our  method  of  evaluating  assertions  is  sensible. 

The  soundness  of  our  Hoare  logic  does  not  require  that  every  2issertion  used  in  a 
proof  be  observable.  Instead  we  only  require  that  the  preconditions  of  function  and 
operation  specifications  and  the  assertions  appearing  in  the  rules  [conseq]  and  [carry]  are 
observable.  This  requirement  is  restrictive,  but  it  is  needed  for  the  proof  of  the  soundness 
of  our  Hoare  logic  given  above. 

However,  as  a  practical  matter  one  can  hardly  use  assertions  that  are  not  observable 
in  proofs,  since  the  rules  [conseq]  and  [carry]  are  used  with  great  regularity. 

We  do  not  know  whether  the  observability  restrictions  of  our  Hoare  logic  are  also 
necessa’-y  for  the  soundness  of  our  verification  technique.  The  difficulty  can  be  illustrated 
by  the  non-observable  MP-assertion  “v  =  x,”  where  v  emd  x  have  nominal  type  Mob. 
Consider  an  environment  t]  defined  on  these  identifiers  in  which 

77(v)  =  A1Iins(ins(new(PSchd,true)  ,1)  ,2)|(C, 0)  (7.60) 

T]{x)  =  Af|ins(ins(new(PSchd, false) ,  1)  ,2)](C,0).  (7-61) 

Since  the  two  instances  of  PSchd  have  the  same  set  of  waiting  integers,  we  have  {C,r])  [= 
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V  =  X,  even  though  the  two  instances  of  PSchd  are  not  equal.  However,  the  imitates 
relation  with  respect  to  type-safe  NOAL  programs  is  so  strong  that  we  cannot  see  how 
using  the  assertion  “v  =  x”  as  a  precondition  of  a  function  specification  would  allow  us 
to  draw  invalid  conclusions  from  our  Hoare  logic. 

So  it  is  an  open  problem  whether  the  observability  requirements  of  our  Hoare  logic 
are  necessary  for  soundness. 


Chapter  8 
Discussion 


111  tins  diaptcT  we  discuss  how  tlie  results  of  the  previous  chapters  may  he  applied  to 
otluu’  programming  languages,  what  extensions  to  our  algeljraic  models  are  needed  for 
practical  applications,  and  future  work. 

8.1  Simulation  in  Other  Programming  Languages 

Various  languages  differ  in  their  ability  to  express  certain  observations  on  abstract  typc*s. 
This  is  because  a  program  must  do  its  work  using  the  operations  of  the  given  types.  For 
example,  consider  an  object-oriented  programming  language  that  has  neither  an  angelic 
choice  operator  nor  parallelism.  The  result  of  an  angelic  choice  between  two  generic 
invocations  cannot  be  expressed  in  such  a  language,  because  there  is  no  way  to  run  the 
two  generic  invocations  “in  parallel”  and  choose  a  result  of  one  that  halts.  Because 
NOAL  includes  angelic  choice,  it  is  capable  of  expressing  such  observations. 

In  Chapter  6  we  showed  that  simulation  relations  that  relate  every  object  of  a  sub¬ 
type  to  every  object  of  a  supertype  determine  a  subtype  relation  (with  respect  to  the 
set  of  all  type-safe  NOAL  programs).  Therefore,  if  one’s  programming  language  is  less 
powerful  than  NOAL  in  the  sense  that  each  observation  described  by  that  language  is 
also  an  observation  described  by  a  type-safe  NOAL  program,  then  simulation  relations 
also  determine  subtype  relations  for  that  language.  Similarly,  for  such  a  weaker  language, 
simulation  relations  should  be  useful  for  Hoare-style  verification  as  in  Chapter  7. 

On  the  other  hand,  if  a  language  lacks  the  constructs  of  NOAL  and  built-in  types  like 
the  streams  of  our  specification  language,  there  may  be  a  weaker  definition  of  simulation 
relations  for  such  a  language  that  could  serve  as  a  basis  for  Hoare-style  verification. 
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8.2  Extensions  Needed  for  Practical  Applications 

Two  extensions  of  our  results  are  needed  if  they  are  to  be  directly  used  in  “real”  languages 
such  as  Smalltalk-80  or  Trellis/Owl.  These  extensions  would  eliminate  limitations  of  our 
algebraic  models  of  type  specifications. 

The  most  importajit  extension  would  be  to  model  mutable  types  and  extend  our 
definition  of  subtype  relations  and  our  verification  techniques  to  handle  mutation.  Our 
algebraic  models  are  only  suited  for  modeling  immutable  types;  that  is,  types  with  no 
time-varying  state.  By  contrast,  most  object-oriented  programs  use  mutable  types. 

We  also  did  not  consider  parameterized  abstract  types.  This  is  not  a  severe  limita¬ 
tion,  however,  since  we  can  describe  subtype  relations  and  reasoning  for  instantiations  of 
parameterized  types.  Still,  it  would  be  interesting  to  describe  the  subtype  relationships 
among  parameterized  types  more  directly  and  to  use  such  relationships  to  derive  subtype 
relationships  on  their  instantiations^. 

8.3  Future  Work 

In  this  section  we  focus  on  future  work  in  the  areas  of  specification,  verification,  and 
language  design.  Before  turning  to  these  areas  we  briefly  state  some  open  problems. 

The  following  is  a  list  of  various  technical  problems  that  this  dissertation  h^ls  left 
open. 

•  What  is  the  relationship  between  the  proof  theory  of  a  subtype  and  the  proof  theory 
of  its  supertypes?  That  is,  how  can  one  characterize  subtype  relations  using  the  set 
of  valid  assertions  that  can  be  made  about  the  objects  of  various  abstract  types? 
Our  definition  of  subtype  relations  is  model- theoretic. 

•  What  conditions  on  specifications  and  observations  guarantee  that  there  is  a  largest 
subtype  relation? 

•  Does  every  subtype  relation  with  respect  to  the  set  of  type-safe  NOAL  programs  de¬ 
termines  simulation  relations  that  witness  that  relation?  That  is,  does  the  converse 
of  Theorem  6.3.2  hold?  This  appears  to  be  a  hard  problem  [Nip87]. 

^  A  related  question  is  what  kind  of  parameterization  is  necessary  or  useful  in  a  language  with  inclusion 
polymorphism. 
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•  Are  the  observability  conditions  of  our  Hoare  logic  necessary  for  the  soundness  of 
program  verification? 

8.3.1  Future  Work  on  Specification 

During  design  and  maintenance,  one  sometimes  adds  a  new  abstract  type  to  one’s  pro¬ 
gram.  If  one  already  knows  a  subtype  relation  on  the  old  types,  the  following  questions 
arise. 

•  What  conditions  on  the  specification  of  the  new  type  will  ensure  that  the  old 
subtype  relation  is  still  a  subtype  relation  on  the  new  specification? 

•  What  has  to  be  shown  to  add  new  subtype  relationships  involving  the  new  type  to 
the  old  subtype  relation? 

Answers  to  these  questions  would  allow  more  modular  proofs  of  subtype  relations. 

Another  question  is  whether  one  can  factor  proofs  of  subtype  relationships  by  taking 
advantage  of  controlled  inheritaince  of  specifications.  For  example,  if  the  specification 
of  a  type  S  incorporates  the  specification  of  a  type  T,  then  it  should  be  possible  to 
take  advantage  of  this  relationship  when  proving  that  S  is  a  subtype  of  T.  However, 
such  techniques  will  probably  depend  on  a  proof-theoretic  characterization  of  subtype 
relations. 

Finally,  there  is  work  to  be  done  in  overcoming  the  limitations  of  our  specification 
language.  These  limitations  are  discussed  in  Chapter  4. 

8.3.2  Future  Work  on  Verification 

An  important  extension  to  our  techniques  for  verification  would  be  to  support  the  ver¬ 
ification  of  modules  that  implement  abstract  types  (classes).  There  are  two  aspects  to 
this  problem.  The  first  involves  showing  that  a  class  meets  the  specification  of  the  type 
it  purports  to  implement  in  the  presence  of  inclusion  polymorphism.  This  should  be 
straightforward,  given  our  results  on  program  verification,  but  there  may  be  some  sub¬ 
tleties  that  we  do  not  yet  understand.  The  second  aspect  is  how  to  factor  the  proof  of 
correctness  for  a  subclass  to  take  advantage  of  the  proof  of  correctness  of  its  superclasses. 


174 


To  make  our  results  directly  applicable  to  existing  languages,  our  techniques  for  ver¬ 
ification  need  to  be  extended  to  cover  imperative  languages.  However,  it  should  not  be 
difficult  to  adapt  our  Hoare-style  proof  system  to  handle  imperative  languages  where 
aliasing  of  mutable  objects  is  prohibited. 

8,3.3  Future  Work  on  Language  Design 

In  this  subsection  we  discuss  some  directions  for  future  work  in  language  design. 

One  long-range  project  would  be  to  design  an  object-oriented  programming  language 
that  would  support  inclusion  polymorphism,  subtyping,  inheritance,  and  program  ver¬ 
ification.  Such  a  language  should  have  a  type  system  that  can  ensure  obedience  to  a 
subtype  relation.  However,  it  is  too  early  to  tell  what  other  features  a  language  would 
need  to  support  program  verification.  For  example,  we  do  not  know  what  features  of  an 
inheritance  mechanism  help  or  hinder  verification. 

A  more  modest  language  design  project  would  be  to  solve  the  name-clash  (or  interface 
control)  problem  for  languages  with  generic  invocation  mechanisms  [LL85].  In  a  language 
with  generic  invocation,  each  object’s  instance  operations  form  a  behavioral  interface  that 
is  analogous  to  the  behavioral  interface  of  an  abstract  type.  However,  in  all  languages 
with  generic  invocation  mechanisms  that  we  know,  there  is  no  way  to  change  an  object’s 
interface.  Therefore  each  object  presents  the  same  interface  to  all  parts  of  a  program 
(except  for  the  class  that  implements  the  object’s  behavior).  It  can  be  difficult  and  costly 
to  combine  independently  designed  program  parts  that  assume  that  the  same  instance 
operation  means  different  things.  Furthermore,  subtyping  depends  on  object  interfaces. 
For  example,  a  type  Int3  that  behaves  like  IntTriple,  but  heis  instance  operations 
named  fst  and  snd,  will  not  be  a  subtype  of  IntPair  even  though  instances  of  type 
Int3  otherwise  behave  like  instances  of  IntPair.  A  mechanism  to  mediate  between 
independently  designed  abstractions  with  fixed  interfaces  is  a  feature  of  several  languages 
without  generic  invocation  mechanisms  (e.g.,  Argus  [LDH*87]  and  Ada  [Ada83]),  where 
one  can  change  the  interface  of  a  type  parameter.  In  a  language  with  a  generic  invocation 
mechanism,  one  wants  to  be  able  to  change  the  interfaces  of  objects.  The  ability  to  change 
object  interfaces  could  also  be  exploited  to  provide  access  control  for  objects  [JL76]  [JL78]. 


Chapter  9 

Summary  and  Conclusions 


In  this  chapter  we  offer  a  high-level  summary  of  our  results  and  their  significance  as  well 
as  some  conclusions  about  programming  and  programming  language  design. 

9.1  Summary  of  Results 

The  two  main  results  in  this  dissertation  axe  a  new  definition  of  subtype  relations  and 
new  techniques  for  the  specification  and  verification  of  object-oriented  programs  that 
exploit  inclusion  polymorphism. 

We  have  given  a  precise  definition  of  subtype  relations.  This  definition  embodies  the 
intuition  that  each  instance  of  a  subtype  imitates  some  instance  of  that  type’s  supertypes. 
So  programs  can  manipulate  instances  of  a  subtype  as  if  they  were  instances  of  that  type’s 
supertypes  without  surprising  results. 

The  most  important  property  of  our  definition  of  subtype  relations  is  that  it  allows  ab¬ 
stract  types  to  be  compared,  based  on  their  specifications.  Most  other  work  on  subtyping 
only  describes  subtype  relationships  for  a  fixed  set  of  built-in  types  (e.g.,  [Car84]).  Our 
definition  also  allows  incompletely  specified  and  nondeterministic  types  to  be  compared, 
so  it  is  more  widely  applicable  than  Bruce  and  Wegner’s  definition  [BW87]. 

We  allow  nondeterminism  in  algebraic  models  and  in  observations  because  many 
interesting  abstract  types  are  nondeterministic  and  because  nondeterminism  allows  one 
more  freedom  to  leave  implementation  decisions  open. 

To  deal  with  incomplete  specifications  we  have  taken  a  loose  view  of  the  semantics 
of  a  specification;  that  is,  the  semantics  of  a  specification  is  a  set  of  algebraic  models 
instead  of  a  single  model  such  as  the  initial  or  final  model.  A  loose  view  of  specifications 
enables  the  definition  of  subtype  relations  to  be  applied  even  to  specifications  for  which 
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no  single  model  captures  all  the  desired  behaviors. 

VVe  have  described  a  way  to  evaluate  assertions  that  are  tailored  to  nominal  types  in 
programs  that  exploit  inclusion  polymorphism.  This  method  uses  the  imitates  relation 
and  nominal  environments.  It  allows  us  to  write  specifications  for  functions  and  programs 
that  exploit  inclusion  polymorphism.  We  have  shown  that  this  method  is  sensible  for 
reasoning  about  environments  that  obey  a  subtype  relation. 

Finally,  we  have  presented  a  logic  for  Iloare-style  verification  of  NOAL  programs. 
This  logic  is  novel  in  that  it  allows  one  to  translate  assertions  tailored  to  a  subtype  into 
assertions  that  are  tailored  to  a  supertype.  Symbolic  verification  of  NOAL  programs  is 
done  as  follows.  One  must  first  find  simulation  relations  that  witness  the  presumed  sub- 
type  relation  of  the  abstract  type  specification  referenced  by  one’s  program  specification. 
These  simulation  relations  are  then  used  to  derive  axioms  for  translating  assertions.  One 
then  uses  the  proof  rules  to  prove  that  the  purported  implementation  meets  the  specifi¬ 
cation,  in  the  usual  way.  If  these  conditions  (and  a  few  minor  technical  ones)  are  met, 
then  the  purported  implementation  satisfies  the  program  specification.  This  is,  as  far 
as  we  know,  the  first  systematic  technique  for  the  verification  of  programs  that  exploit 
inclusion  polymorphism. 

9.2  Conclusions  for  Programmers 

In  this  section  we  describe  the  significance  of  our  results  and  some  lessons  for  program¬ 
mers  who  work  with  object-oriented  programming  languages  that  have  generic  invocation 
mechanisms. 

Our  work  gives  programmers  a  new  tool:  subtype  relations.  Subtype  relationships  are 
similar  to  satisfaction  relationships  among  abstract  types;  the  difference  is  largely  that  the 
S3'ntax  of  class  operations  does  not  matter  for  a  subtype  relationship.  Subtype  relations 
are  useful  during  program  design,  where  they  can  help  track  the  evolution  of  abstractions, 
limit  the  effects  of  specification  changes,  and  group  and  classify  related  types  [Lis88].  In  a 
system  like  Smalltalk-SO  where  classes  are  also  objects,  subtype  relationships  among  the 
types  of  classes  can  also  be  used  in  similar  ways.  We  have  shown  how  subtype  relations 
can  be  used  to  write  polymorphic  specifications  and  to  support  careful  reasoning. 

Perhaps  the  most  important  lesson  for  programmers  is  the  most  basic  one:  subtype 
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relationships  are  based  on  observable  behavior  and  they  have  nothing  to  do  with  how 
a  type  is  implemented  [SnyS6a].  That  is,  a  subtype  is  not  a  subclass.  While  it  is 
usefu'  to  record  inheritance  relationships  among  implementations  in  a  subclass  relation, 
one  should  organize  abstract  types  by  a  subtype  relation.  This  distinction  between 
subclasses  and  subtypes,  when  properly  understood,  can  be  a  powerful  tool  for  separation 
of  concerns.  Subtype  relations  allow  one  to  reason  abstractly  about  instances  of  abstract 
types.  Subclass  relations  allow  one  to  reason  about  how  instances  are  implemented. 

The  distinction  between  subtypes  and  subclasses  is  not  just  academic.  If  one  passes 
an  argument  whose  type  is  not  a  subtype  of  the  expected  formal  argument  type  to  a 
procedure,  one  has  no  guarantee  that  the  procedure  will  act  as  desired.  If  one  uses  an 
instance  of  a  subclass  where  instances  of  a  superclass  are  expected,  then  one’s  programs 
may  behave  in  unexpected  ways.  To  prevent  such  problems  one  should  ensure  that 
each  expression  denotes  an  object  whose  type  is  a  subtype  of  the  expression’s  nominal 
type.  If  one  programs  in  a  statically  type-checked  language  like  Trellis/Owl,  then  the 
type  system  can  check  this  second  property  automatically,  once  it  has  been  told  about  a 
subtype  relation. 

An  understanding  of  subtype  relations  also  gives  programmers  a  strategy  for  testing 
modules  that  exploit  inclusion  polymorphism.  That  is,  one  should  concentrate  on  tests 
where  the  argument  types  are  the  same  as  the  nominal  types  of  the  module’s  formal 
arguments.  If  there  are  problems  in  the  module  that  can  be  uncovered  by  testing,  this 
strategy  can  uncover  them. 

9.3  Conclusions  for  Language  Designers 

In  this  section  we  discuss  some  lessons  for  designers  of  new  programming  languages  with 
generic  invocation  mechanisms. 

9.3.1  Languages  Should  Have  Declared  Subtype  Relations 

If  one  is  designing  a  type  system  for  an  object-oriented  programming  language  with  a 
generic  invocation  mechanism,  then  subtype  relations  should  be  a  part  of  that  type  sys¬ 
tem.  ( OthrTwise  progranjs  will  not  be  able  to  exploit  inclusion  polymorphisnu)  Perhaps 
the  most  important  lesson  that  emerges  from  our  work  for  language  designers  is  to  make 


the  programmer  declare  the  subtype  relation  for  abstract  types. 

The  reason  this  lesson  is  so  important  is  that  the  programming  language  cannot,  in 
general,  find  a  nontrivial  subtype  relation  on  the  types  of  a  program.  Most  programming 
languages  are  not  designed  to  include  behavioral  specifications  as  part  of  programs.  Each 
module  is  a  specification  of  that  module’s  behavior,  but  it  is  not  the  specification  that 
the  programmer  worked  from  during  design  (and  verification).  Even  if  the  program  text 
included  a  behavioral  specification,  the  problem  of  finding  a  nontrivial  subtype  relation 
on  the  types  of  a  specification  is  undecidable  in  general.  It  seems  more  straightforward  to 
let  the  programmer  declare  a  subtype  relation.  Finally,  a  programmer  may  wish  to  work 
in  a  subset  of  a  full  language,  and  thus  may  only  be  concerned  with  subtype  relations 
with  respect  to  that  subset  of  programs. 

On  the  other  hand,  some  mild  restrictions  on  what  subtype  relations  can  be  declared 
are  probably  unavoidable  if  one  wants  to  use  a  static  type  system  to  ensure  that  every 
environment  obeys  the  declared  subtype  relation.  For  example,  to  ensure  obedience 
to  a  subtype  relation  both  the  NOAL  and  Trellis/Owl  type  systems  require  that  the 
declared  subtype  relation  be  reflexive  and  transitive  and  that  each  instance  operation 
of  a  supertype  is  also  an  instance  operation  of  each  of  that  type’s  subtypes  (with  an 
appropriate  signature). 

9.3.2  TypeOf  Operators  Cause  Problems  for  Reasoning 

Another  lesson  for  language  designers  is  that  operators  that  tell  the  type  of  an  object 
cause  problems  for  reasoning  and  should  thus  be  avoided.  This  is  a  new  twist  on  an 
old  lesson:  if  one  wants  to  reason  about  abstract  types  based  on  their  specifications, 
then  one’s  language  should  only  allow  objects  to  be  observed  by  invoking  their  instance 
operations. 

A  typeOf  operator  returns  the  type  of  an  object  as  a  string.  For  example,  the  program 
typeOf  (x)  will  give  different  results  in  environments  where  x  denotes  objects  of  different 
types.  Such  an  operator  destroys  subtyping.  It  is  easy  to  show  that  a  subtype  relation 
with  respect  to  the  set  of  all  programs  that  use  typeOf  cannot  relate  different  types. 
So  we  cannot  directly  use  our  methods  to  reason  about  an  implementation  that  uses  a 
typeOf  operator. 


Appendix  A 

Summary  of  Notation 


In  this  appendix  we  summarize  the  notation  used  in  earlier  chapters.  We  also  give  the 
signatures  of  the  questions  posed  in  earlier  chapters,  where  these  questions  usually  take 
the  form  of  definitions. 

Table  A.l  lists  some  primitive  domains,  which  are  just  sets.  Algebras  are  heteroge¬ 
neous  (i.e.,  sorted),  so  one  should  think  of  Object  as  the  disjoint  union  of  several  sets 
(one  for  each  sort).  In  this  appendix  the  carrier  sets  of  various  sorts  are  not  distinguished 
for  the  sake  of  simplicity. 

As  in  Table  A.l,  phrases  are  often  abbreviated.  For  example,  “GenOpSym”  should 
be  read  as  “generic  operation  symbol.” 

The  syntax  of  the  terms  in  our  specification  language  is  given  in  Figure  2.4  on  page  31. 
The  syntax  of  NOAL  expressions  is  given  in  Figure  3.1  on  page  46. 

The  following  tables  are  organized  by  topic,  which  is  roughly  by  chapter,  except  that 
the  syntax  and  semantics  of  specifications  and  programs  are  treated  separately.  For  each 


Notation  for  Members 

Table  A.l 
Name 

:  Primitive  Domains 
description 

o,q,re 

Object 

instances 

S,  T  e 

Type 

type  symbols 

S,  T  e 

Sort 

sort  symbols 

gg-T  ^ 

OpSymbol 

operation  symbols  (of  algebras) 

X,  y,  z  e 

Identifier 

identifiers 

f  e 

Funident 

function  identifiers 

ge 

GenOpSym 

generic  operation  symbols 

f  e 

TrtFunSym 

trait  function  symbols 

true,  false  6 

Bool 

the  booleans 

P,  Q.  R,  e 

Term 

logical  formulas 

E  e 

Expr 

programming  language  expressions 
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o,q,r  6  CarrierSet 
o,q,r  G  TypeCarrier 
o,q,r  G  PossRes 
Q,R  £  SetOfPossRes 
/Ifg  ^  G  Operation 
Ai  G  TraitFun 
Aops  G  SetOfOperation 
Atfuns  G  SetOfTrtFun 

A,B,C  G  Algebra 

SPEC  G  SpecSemantics 


Table  A. 2:  Algebras  and  Related  Concepts 


=  Object 
=  Object 
=  TypeCarrier 
=  {PossRes} 

=  TypeCarrier*  SetOfPossRes 
=  Object*  Object 
=  {Operation} 

=  {TraitFun} 

(CarrierSet,  TypeCarrier, 
SetOfTrtFun,  SetOfOperation 
=  {Algebra} 


_ Table  A. 3:  Questions  for  Algebras 

has  type?  :  Object,  Algebra,  Type  — »  Bool 


topic  there  are  one  or  two  tables.  One  table  is  organized  like  Table  A.l  and  describes 
the  domains  related  to  that  topic.  The  second  table  lists  the  significant  questions  (i.e., 
definitions)  related  to  that  topic. 

The  following  conventions  are  used  to  describe  domains.  Each  entry  has  the  form 
d  G  D  =  E'  meaning  that  d  is  the  typical  notation  for  an  element  of  the  domain  D, 
which  is  defined  by  E' .  For  example 

q  G  Env  =  Typedident  Object 

means  that  q  is  used  to  denote  environments,  which  are  mappings  from  typed  identifiers 
to  objects.  The  following  notations  are  used  in  describing  domains.  The  notation  {£)} 
means  a  nonempty  set  of  elements  from  the  domain  named  D.  The  notation  D*  stands 
for  all  finite  tuples  of  zero  or  more  Ds.  The  notation  Di  — >  denotes  the  set  of  functions 
from  a  subset  of  D\  to  Dj.  The  notation  (Z>i,£>2)  stands  for  the  set  of  all  pairs  whose 
first  element  is  from  Di  and  whose  second  element  is  from  D2- 

Table  A. 2  describes  algebras  and  some  related  operations  from  Chapter  2, 

Table  A. 3  describes  questions  for  algebras. 

Table  A.4  describes  the  concepts  used  to  describe  the  syntax  and  semantics  of  the 
type  specification  language  of  Chapter  2.  Also  included  are  concepts  used  to  describe 
the  syntax  of  algebras.  The  structure  of  Larch  traits  is  not  further  described.  The  ab- 
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Table  A.4:  Type  Specifications  and  Related  Concepts 


SORTS  G  SetOfSorts 

=  {Sort} 

TYPES  G  SetOfTypes 

=  {Type} 

V  G  VisibleTypes 

=  {Type} 

TFUNS  G  SetOfTrtFunSym 

=  {TrtFunSym} 

OPS  G  SetOfOpSym 

=  {OpSymbol} 

E  G  Signature 

_  ?  SetOfSorts,  SetOfTypes,  VisibleTypes,  \ 

^  SetOfTrtFunSym,  SetOfOpSym  ) 

T  G  Trait 

= 

P,  Q,  R  G  Assertion 

=  Term 

P,  R  E  Requires 

=  Assertion 

Q  G  Effect 

=  Assertion 

g  G  OpSpec 

=  (GenOpSym,NomSig,Requires, Effect) 

T  G  OperationsSpec 

=  {OpSpec} 

<  G  BinRelTyp 

=  Type,  Type  — »  Bool 

SPEC  G  TypeSpec 

=  (SetOfTypes,  BinRelTyp,  Trait,  OperationsSpec) 

A  G  FunStruct 

=  (CarrierSet,  SetOfAbsFun) 

A(s)  G  Reduct  Of 

=  Algebra,  Signature  Algebra 

SIG  G  SigOfSpec 

=  TypeSpec  Signature 

SIG  G  SigOfAlg 

=  Algebra  — »  Signature 

rj  G  ExtendedEnv 

=  Term  — »  Object 

_ Table  A. 5:  Questions  for  Type  Specifications 

satisfies?  :  Operation,  OpSpec  — »  Bool 
satisfies?  :  Algebra,  TypeSpec  — ♦  Bool 


breviation  “FunStruct”  stands  for  the  “functional  structure”  of  an  algebra.  The  domain 
“BinRelTyp”  should  be  read  ais  “binary  relations  on  types”  or  “presumed  subtype  rela¬ 
tions.”  The  notation  where  S  is  a  signature,  means  the  S-reduct  of  the  algebra  A. 
The  notation  rj  denotes  the  extension  of  the  environment  77  to  a  mapping  from  terms  to 
the  elements  of  the  carrier  set  of  the  algebra  in  the  range  of  t]  (see  Chapter  2). 

Table  A. 5  describes  the  definitions  satisfaction  from  in  Chapter  2. 

Table  A.6  describes  the  concepts  used  to  define  observations  in  Chapter  3. 


_ Table  A.6:  Observations  and  Related  Concepts 

x:  T  6  Typedident  =  (Identifier,  Type) 

Tj  G  Env  =  Typedident  — »  Object 

P  G  Observation  =  Algebra,  Env  -+  SetOfPossRes 
OBS  G  SetOfObs  =  {Observation} _ 


_ Table  A.7:  Programming  Language  Concepts _ 

X ,  Z  €  SetOfldent  =  {Typed Went) 

M  €  Denotation  =  Expr  — +  Observation 

Generic  £  GIMap  =  GenOpSym,  TypeCarrier*,  Algebra  —*  OpSymbol 

GOP  £  SetOfGenOp  =  (GenOpSym) 

S  — T  G  NomSig  =  (Type*,  Type) 

(S  — ♦  T)  €  SetOfNomSig  =  {NomSig} 

NornSig  £  NomSigMap  =  GenOpSym  — »  SetOfNomSig 
//,  X  £  TypeAssumptions  =  (TypedWent) 

C  £  DomainOrder  =  Object,  Object  — >•  Bool 
□e  £  DomOrdForSets  =  SetOfPossRes,  SetOfPossRes  — >  Bool 
Q  £  ClosiiicOf  =  SetOfPossRes  — »  SetOfPossRes  _ 


Table  A. 8:  Questions  for  Programming  Language 


has  nominal  type? 

Expr,  NomSigMap,  BinRelTyp,  Type  — >  Bool 

safe? 

BinRelTyp,  NomSigMap  — v  Bool 

obeys? 

Algebra,  Env,  BinRelTyp  — »  Bool 

monotonic? 

Operation  — »  Bool 

strongly  monotonic? 

Operation  — >  Bool 

continuous? 

Operation  — ♦  Bool 

Table  A.7  describes  the  concepts  used  in  Chapter  3  and  Appendix  C  to  give  semantics 
to  NOAL  programs  and  to  describe  the  NOAL  type  system.  The  operator  that  takes  the 
closure  of  a  set  is  written  as  an  overbar;  that  is,  the  closure  of  a  set  Q  is  written  Q. 

Table  A. 8  describes  the  major  definitions  of  Chapter  3  and  Appendix  C. 

Table  A. 9  describes  the  concepts  for  function  specifications  from  Chapter  4,  and 
table  A.  10  describes  the  major  definitions. 

Table  A. 11  describes  subtype  relations  from  Chapter  5. 

Table  A.  12  describes  typed  families  of  relations,  abbreviated  “FamilyOfRel,”  from 
Chapter  6.  Table  A.  13  describes  the  definition  of  simulation  relations  from  Chapter  6. 

Table  A.  14  describes  the  concept  of  a  Hoare-triple  from  Chapter  7  and  table  A.  15 
describes  related  definitions. 


_ Table  A .9:  Function  Specification  Concepts 

f  £  FunSpec  =  (FunWent, NomSig, TypeSpec,Requires, Effect) 
cq  £  CharObserv  =  Observation 
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nominal? 

imitates? 

models? 

proper? 

satisfies? 

observable? 


_ Table  A. 10:  Questions  for  Function  Specifications 

:  Algebra,  Env  — »  Bool 

:  Algebra,  Env,  Algebra,  Env,  SetOfObs  — Bool 
:  Algebra,  Env,  Assertion  Bool 
:  Env  — >  Bool 

:  FunSpec,  Operation  — ►  Bool 
:  Assertion,  SetOfObs  Bool 


_ Table  A.ll:  Subtype  Relations _ 

subtype  relation?  :  SpecSemantics,  BinRelTyp,  SetOfObs  —*■  Bool 


_ Table  A.  12:  Typed  Families  Of  Relations 

€  FamilyOfRel  =  {  TypeCarrier,  TypeCarrier  — >  Bool  } 


_ Table  A.  13:  Questions  for  Simulation _ 

bistrict?  ;  Algebra,  Algebra,  FamilyOfRel  — >  Bool 

V-identical?  :  Algebra,  Algebra,  FamilyOfRel  Bool 

homomorphic  rel?  :  Algebra,  Algebra,  FamilyOfRel,  NomSigMap,  BinRelTyp  —>■  Bool 

simulation  rel?  :  Algebra,  Algebra,  FamilyOfRel,  NomSigMap,  BinRelTyp  —*■  Bool 

universal  model?  :  Algebra,  SpecSemantics,  SetOfObs  — f  Bool 


_ Table  A. 14:  Verification  Concepts _ 

P  €  PreCond  =  Assertion 

Q  €  PostCond  =  Assertion 

P  {y  E}  Q  E  HoareTriple  =  (PreCond,Identifier, Expression, PostCond) 


_ Table  A.  15:  Questions  for  Verification 

models?  :  Algebra,  Env,  HoareTriple  — >  Bool 

valid?  :  SpecSemantics,  BinRelTyp,  HoareTriple  — »  Bool 
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Appendix  B 

Visible  Types  and  Streams 


In  this  appendix  we  describe  the  models  of  the  visible  types  fixed  by  our  type  specification 
language.  These  types  are  Bool,  Int  and  two  corresponding  stream  types:  BoolStream 
and  Int  St  ream. 

The  algebra  for  the  type  Bool  is  found  in  Figure  2.1  on  page  26. 

Our  algebra  for  the  type  Int  is  found  in  Figure  B.l. 

The  types  IntStream  and  BoolStream  are  used  to  model  output.  The  cons  operation 
of  each  type  is  lazy;  that  is,  cons  is  not  strict  in  its  second  argument.  In  Figure  B.2  on 
page  188  we  give  an  algebraic  model  of  IntStream.  The  model  of  BoolStream  is  similar 
and  can  be  obtained  by  replacing  Bool  for  Int  throughout. 

The  carrier  set  of  IntStream  is  defined  using  the  operator  Stream  [Bro86],  defined  as 

Stream{I)  =  {/*  U  (/*  x  {±})  U  (B.l) 


where 

•  /*  denotes  the  set  of  finite  streams,  which  are  finite  sequences  of  elements  of  7, 
such  as  the  empty  stream  ()  and 

•  I"  X  {±}  denotes  the  set  of  partial  streams,  which  are  finite  sequences  ending  in  ±, 
such  as  (I’l,  i2,  ^3, -L)  and  the  totally  undefined  stream  ±  =  (J_),  and 

•  /'^  denotes  the  set  of  infinite  streams,  such  as  (fj,  ^2,  *3,  •  •  •)• 

The  definition  of  the  restintstreaM-.intstrea*  operation  also  needs  some  explanation. 
The  rest  operation  is  strict,  as  Figure  B.2  shows,  since  all  trait  functions  are  strict.  Fur¬ 
thermore,  one  should  think  of  the  rest  operation  as  requiring  that  its  argument  stream 
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Figure  B.l:  Model  of  the  visible  type  Int. 
Carrier  sets 

5int  =  {±,0,1, -1,2, -2,...} 

filntClass  *=  {±,/n/} 


Trait  Functions 
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otherwise 
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^equal?int  int_BooI  ) 

{5#.eq#(*,i)} 

-Int.Int^Bool  ^  ) 

def 

{5#<#(t,j)} 
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not  be  empty,  since  the  set  of  possible  results  of  invoking  rest  on  an  empty  stream  is  the 
entire  carrier  set  of  IntStream.  Finally,  note  that  the  consintstrea*,int-»intstrea»  opera¬ 
tion  is  not  strict  in  its  stream  argument,  as  this  is  how  partial  streams  are  constructed. 


1S8 


Figure  B.2:  Model  of  the  visible  type  IntStream. 
Carrier  sets 

^Intstrea.  5fream({0, 1, -1, .  .  .  , 
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Appendix  C 

Recursively-Defined  NOAL  Functions 


In  this  appendix  we  describe  the  semantics  of  systems  of  recursively-defined  functions  in 
NOAL  and  we  prove  the  substitution  property  for  NOAL  functions. 

C.l  Semantics  of  NOAL  Functions 

The  semantics  of  NOAL  functions  are  discussed  informally  in  Chapter  3.  In  this  section 
we  give  a  formal  semantics  for  systems  of  mutually  recursive  NOAL  functions.  Our 
semantics  follows  Broy’s  discussion  of  the  semantics  of  AMPL  [Bro86,  Page  20].  We  also 
describe  how  the  carrier  sets  of  an  algebra  are  viewed  as  domains  and  an  assumption 
about  the  domain  ordering  on  the  carrier  sets  of  algebras  that  can  be  observed  by  NOAL 
programs. 

Throughout  this  section  we  fix  a  signature  S  =  {SORTS,  TYPES,  V ,  TFUNS,  OPS) 
and  a  E-algebra  1. 

C.1.1  Domains  and  Domain  Orderings 

Recall  that  J.,  which  represents  nontermination  and  errors,  is  an  element  of  the  carrier  set 
of  each  type  in  an  algebra.  To  define  the  semantics  of  NOAL  (in  particular  the  semantics 
of  recursive  function  definitions),  we  use  a  partial  order  C  on  each  type’s  carrier  set  that 
makes  that  carrier  set  a  domain,  that  is  a  pointed  complete  partial  order. 

The  following  definition  of  a  pointed  complete  partial  order  is  taken  from  [Sch86, 
Page  111].  For  a  partially  ordered  set  D,  a  subset  Q  of  Z)  is  a  chain  if  it  is  nonempty 
and  for  all  qi,q2  G  Q,  either  qi  E  92  or  92  E  9i-  A  complete  partial  order  is  a  set  D 
with  a  partial  order  C,  such  that  every  chain  in  D  has  a  least  upper  bound  in  D.  The 
least  upper  bound  of  a  chain  Q  Q  D,  written  lub((5),  is  the  smallest  element  of  D  that 
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is  at  least  as  large  as  every  element  of  Q.  A  pointed  complete  partial  order  is  a  complete 
partial  order  that  has  a  least  element,  ±. 

From  now  on  we  will  simply  refer  to  pointed  complete  partial  orders  as  domains.  We 
are  primarily  interested  in  flat  domains,  since  the  semantics  for  recursive  functions  that 
we  use  assumes  that  each  carrier  set,  except  for  the  carrier  sets  of  the  stream  types,  is  a 
flat  domain  [Bro36,  Page  7]. 

Definition  C.1.1  (flat  domain).  A  domain  is  flat  if  and  only  if  for  all  elements  q  and 
9  E  if  and  only  if  <7  =  r  or  <7  =  J.. 

As  usual,  we  write  q  O  r  li  q  Q  r  and  q  ^  r.  Therefore,  in  a  flat  domain,  g  C  r  if  and 
only  if  g  =  ±. 

Our  assumptions  about  the  partial  order  C  on  a  carrier  set  are  as  follows.  Let  E  be  a 
signature  and  let  .4  be  a  S-algebra.  Recall  that  the  semantics  of  the  visible  types  is  fixed 
by  convention;  that  is,  the  same  reduct  is  used  in  all  algebras  for  the  visible  types.  We  < 

a.ssume  that  Bool  is  a  visible  type  with  proper  elements  true  and /a/se;  these  are  needed 
to  define  if  expressions.  We  zissume  that  for  each  visible  type  v,  the  carrier  set  of  v 
comes  equipped  with  a  partial  order  C  (defined  by  convention)  that  makes  Av  a  domain 
with  X  as  its  least  element.  We  further  assume  that  the  carrier  set  of  each  visible  type 
except  BoolStream  and  IntStream  is  a  flat  domain.  For  a  non-visible  type  T,  we  define 
C  so  that  the  carrier  set  of  T  is  a  flat  domain. 

For  example,  our  convention  for  C  on  the  carrier  sets  of  the  visible  types  of  the 
algebraic  models  of  our  specification  language  is  as  follows.  The  carrier  sets  of  Bool  and 
Int  are  flat  domains.  The  carrier  sets  of  BoolStreaun  and  IntStream  are  such  that  if  A 
is  an  algebra  and  g,  r  €  ABooistreami  then  g  C  r  if  and  only  if  either  g  =  r  or  g  is  a  partial 
stream  whose  proper  elements  are  a  prefix  of  r  [Bro86,  Section  2.1]. 

We  also  regard  the  carrier  set  of  A  itself  as  a  domain  formed  by  the  union  of  all  its 
carrier  sets.  That  is,  g  C  r  in  A  if  and  only  if  g  and  r  are  in  the  same  carrier  set  and 
g  C  r.  (Recall  that  X  is  in  each  type’s  carrier  set.) 

For  the  domain  ordering  on  an  algebra  to  be  useful,  it  must  say  something  about  the 
operations  of  the  algebra.  In  particular,  the  operations  of  the  algebra  must  be  monotonic 
and  continuous.  To  define  these  terms,  we  fir.  „  extend  the  partial  order  C  to  tuples  as 
follows;  g  C  r  if  and  only  if  for  all  i,  g,  C  r,.  Since  operations  return  a  set  of  possible 
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results,  we  also  define  an  ordering  Qe  on  sets  of  possible  results.  We  write  Q  Qe  R  if 
for  each  q  G  Q  there  is  some  r  G  R  such  that  9  C  r  [Bro86,  Page  13]. 

Definition  C.1.2  (monotonic).  An  operation  g  is  monotonic  if  and  only  if  for  all  ^1, 
92,  if  9i  E  92,  then  g{qi)  g{q2). 

That  is,  g  is  monotonic  if  whenever  qi^q^  and  rj  G  g{qi)i  then  there  is  some  r2  €  5^(92) 
such  that  ri  E  ’”2- 

To  define  continuous  operations,  we  view  chains  cis  sequences.  A  sequence  in  C  is 
a  nonempty  set  Q  =  {qi  \  i  G  1}  indexed  by  some  well-ordered  set  I  (whose  elements 
are  ordered  by  <)  with  the  property  that,  if  i  <  j,  then  qi  E  9j-  A  well-ordered  set 
is  a  totally-ordered  set  such  that  every  non-empty  subset  has  a  least  element  [Gra79, 
Pagel2].  The  elements  of  a  sequence  form  a  chain  and  conversely  the  elements  of  a  chaiin 
can  be  placed  in  a  sequence.  We  use  one  concept  or  the  other  as  is  convenient. 

Definition  C.1.3  (continuous).  A  monotonic  operation  g  is  continuous  if  and  only  if 
for  every  sequence  inQ,  Q  =  whenever  R  =  {r,}  is  a  sequence  in  E  indexed  by  the 
same  set  as  Q  such  that  for  all  indexes  i,  r<  €  5(9i),  then  lub(i?)  6  flf(lub(Q)). 

Because  we  require  the  operations  of  an  algebra  to  be  continuous,  our  assumption 
that  the  carrier  sets  of  all  types  except  IntStreeim  and  BoolStream  are  flat  domains  is 
restrictive.  That  is,  there  are  some  abstract  types  whose  carrier  sets  cannot  be  consid 
flat  domains  if  their  operations  are  to  be  monotonic  and  continuous.  For  example,  the 
carrier  set  of  Int Stream  cannot  be  a  flat  domain,  since  then  the  cons  operation  would 
not  be  monotonic. 

So  that  we  may  assign  denotations  to  systems  of  mutually  recursive  function  defini¬ 
tions,  we  also  assume  that  each  set  of  possible  results  of  an  algebra’s  operations  is  closed 
with  respect  to  the  algebra’s  domain  ordering  E-  A  set  of  values  is  closed  if  and  only  if  for 
every  chain  Q  Q  D,  its  least  upper  bound,  lub(Q),  is  also  in  D.  This  assumption  ensures 
that  the  set  of  possible  results  of  each  NOAL  expression  is  closed  and  thus  accords  with 
the  principle  of  finite  observability  [Bro86]. 

C.1.2  Semantics  of  Recursive  Functions  in  NOAL 

In  this  subsection  we  give  the  semantics  of  systems  of  mutually  recursive  NOAL  functions. 
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We  begin  by  defining  the  semantics  of  systems  that  do  not  use  angelic  choice.  Fol¬ 
lowing  Broy  we  obtain  approximations  by  eliminating  erratic  choice  operators  ( [] )  and 
textually  expanding  recursive  calls.  Erratic  choices  are  turned  into  different  expansions. 

The  notation  stands  for  the  denotation  of  a  function  definition  named  f 

in  an  algebra  A.  The  denotation  of  a  system  of  function  definitions  does  not  depend 
on  the  surrounding  environment,  because  in  the  body  of  a  recursively  defined  NOAL 
function,  there  can  be  no  free  identifiers  or  function  identifiers,  besides  those  of  the  other 
recursively  defined  functions  and  the  function’s  formal  arguments. 

Fix  an  algebra  A.  Let 

fun  fi(xl  :  S*i)  :  Ti  = 
fun  fm(Xm  :  S^)  :T„,  =  Em 

be  a  mutually  recursive  system  of  NOAL  function  definitions,  where  the  angelic  choice 
operator  (y)  does  not  occur  in  the  Ej. 

When  eliminating  erratic  choice  operators  one  makes  choices  of  what  expressions  to 
execute;  each  such  choice  is  called  a  deterministic  descendant.  An  expression  E"  is  a 
deterministic  descendant  of  an  expression  E'  if  E"  does  not  contain  the  erratic  choice 
operator  ([])  and  can  be  obtained  from  E*  by  replacing  subexpressions  of  the  form  71Q72 
with  either  7i  or  72. 

A  family  of  expressions  is  called  a  choice  family  for  the  system  of  fj  if  for  each 
j,  D(jfl)  is  a  deterministic  descendant  of  Ej^  and  is  a  deterministic  descendant  of 

with  (fun(x'fc  ;  Sk)Ek)  substituted  for  f^  for  each  k.  The  expression  differs 

from  in  that  one  more  recursion  is  unrolled,  thus  is  a  better  approximation 

to  one  computation  of  fj  than  D(jj). 

For  example,  consider  a  system  with  one  recursively  defined  function,  where  f  1  is  the 
function  choose  defined  by 

fun  choose  (x:Int):  Int  *  (x  []  choose(add(x,l))) . 

There  are  infinitely  many  choice  families  for  this  example.  One  choice  family  for  choose 
is  for  all  i,  D(ij)  =  x.  Another  choice  family  has  for  all  i  >  1,  where 

^(1,0)  =  choose(add(x,l)) 

^(1.1)  =  (f'ui  (x:Int)  x)  (add(x,l)). 
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There  is  also  a  choice  family  that  has  an  occurrence  of  choose  in  every  -0(1, <). 

As  usual,  an  everywhere-^  function  is  the  first  approximation  to  recursive  invocations 
in  the  For  each  let  Gj  be  the  function  abstract  of  the  form 

f\in(xj  :  :  Tj  =  bottoin[Tj]. 

To  define  the  meaning  of  each  recursively  defined  NOAL  function,  we  take  the  least 
upper  bounds  of  sequences  of  approximate  results.  Given  a  choice  family,  T)(j,,),  for 
each  j  let  Qj{^  =  {qi)  be  a  sequence  in  C,  where  for  each  i,  qi  is  a  possible  result 
of  Af  [Zl(j,q[G/f]](A,  r;)  and  =  q.  As  Broy  notes,  there  Jire  such  sequences  in  C 

because  the  deterministic  language  constructs  (and  each  operation  of  A)  are  monotonic 
and  because  is  derived  from  by  unrolling  another  recursion.  Note  that 

T>(j_,)[G/f]  is  recursion-free.  For  each  j,  let  DDj{^  denote  the  set  of  all  sequences  Qj{^ 
for  all  choice  families. 

For  the  choose  example,  DDi{Q)  would  be  the  set  consisting  of  the  sequence 
(±,  X,  ±, . . .)  and  edl  sequences  in  C  of  the  form 


n 


for  some  n  >  0. 

The  denotation  is  defined  by 

='  {lub(l3j(9))  I  Qi(q)  €  DDim-  (C.l) 

That  is,  J’(A)[f  j](^  is  the  closure  of  the  set  of  all  the  least  upper  bounds  of  all  sequences 
in  □  from  DDj{^.  The  closure  of  a  set  Q,  written  Q,  is  the  smallest  closed  set  that 
contains  Q.  Taking  the  closure  ensures  that  the  set  of  possible  results  is  closed;  it  might 
otherwise  be  possible  to  form  a  sequence  from  the  lub((5;(^))  whose  least  upper  bound 
was  not  in  the  set. 

For  the  choose  example  we  determine  the  possible  results  of  choose  (0)  as  follows. 
The  least  upper  bound  of  the  sequence  (X,X,X,...)  is  X.  The  least  upper  bound  of  a 
sequences  of  the  form  (X,  X,  X, . . . ,  n,n,n, . . .)  is  n.  So  we  have 


{lub(Q,(0))  I  Qj(0)  €  DD(0))  =  {X,  0, 1 , 2, 3, . . .}. 
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This  set  is  already  closed  in  the  C  ordering  (as  the  carrier  set  of  Int  is  a  flat  domain)  so 
it  is  the  set  of  possible  results. 

The  meaning  of  a  system  of  recursive  function  definitions  that  uses  angelic  choice  uses 
the  meaning  of  a  system  that  does  not  use  angelic  choice  as  a  first  approximation.  Better 
approximations  are  obtained  by  using  earlier  approximations  to  evaluate  recursive  calls. 
The  net  effect  is  that  each  approximation  uses  angelic  choice  for  deeper  recursions  than 
the  previous  approximation  [Bro86,  Page  19). 

Let 

fun  f,(xl  :  S"i)  :  T,  =  E^; 

^m(^m  •  Sjn)  t  =  Em 

be  a  system  ot  mutually  recursive  NOAL  function  definitions.  Let  E^jjo)  be  derived  from 
Ej  by  replacing  all  occurrences  of  the  angelic  choice  operator  ( v)  with  the  erratic  choice 
operator  ( [j ).  Let 

:  S*i)  :  Ti  = 

For  example,  consider  the  function 
fun  choose2  (x:Int):  Int  «  (x  V  choose2(add(x, 1))) . 

For  this  example,  the  system  with  V  replaced  by  []  is 

fun  g(i,o)  (x:Int):  Int  *  (x  [j  choose2(add(x,l))). 

For  each  j,  ^(A)|g(j_o)l  gives  meaning  to  recursive  calls  to  fj.  We  call  the  next 


approximation  obtained  in  this  way  ^(A)[g(j4)J.  In  this  way 

a  family  .F(A)fg(j.,)]  for 

each  j  and  i  is  defined  as  follows.  For  each  natural  number  z. 

(C.2) 

where 

Vi^i)  =  9 

(C.3) 

and  where  for  all  k. 

Vi^k)  =  ^(A)[g(fc,.)J. 

(C.4) 
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That  is,  to  find  the  possible  results  of  ^(A)|g(j,j+i)|(^,  take  the  possible  results  of  Ej, 
which  may  use  angelic  choice,  in  an  environment  where  g  is  bound  to  the  formals  of  fj  and 
is  used  as  an  approximation  to  f  for  all  k.  (The  only  free  identifiers  in  Ej 
are  the  Xj,  and  the  only  free  function  identifiers  are  the  fjt.)  By  construction, 
does  i  levels  of  recursion  using  angelic  choice  and  then  reverts  to  erratic  choice. 


For  the  choose2  example, 

^(>l)[g(i.o)l(0)  =  {±,0,1, 2, 3,...}  (C.5) 

•^(^)I6(1.1)K0)  Vchoose2(add(x,  1))](/1,7/)  (C.6) 

=  {0}U({±.1,2,3,...}\{±})  (C.7) 

=  {0, 1,2,3,...}.  (C.8) 


where  7y(x)  =  0  and  77(choose2)  =  ^(i4)[g(i,o)l-  By  the  definition  of  angelic  choice,  ±  is 
not  a  possible  result  of  the  expression  x  V  choose2(add(x,  1) )  in  t},  because  the  only 
possible  result  of  x  is  0.  The  possible  results  of  ^(-i4)|g(i^,)](0)  for  all  t  >  1  are  also 
{0,1, 2, 3,...}. 

Following  [Bro86,  Page  19],  for  each  j, 

«  n^C'Ofai.oKfl-  (C.9) 

t 

For  the  choose2  example: 

,F(,4)|[choose2l(0)  W  n^(^)[g(i..)l(0)  (C-10) 

t 

=  {0,1,2,3,...}.  (C.ll) 

C.2  The  Substitution  Property  for  NOAL  Functions 

In  this  section  we  prove  the  substitution  property  for  NO.A.L  functions;  that  is  we  give 
the  postponed  proof  of  Lemma  6.2.2. 

Because  the  semantics  of  systems  of  mutually  recursive  function  definitions  involve 
closures  and  least  upper  bounds  of  sequences,  it  is  convenient  to  first  show  that  simulation 
relations  are  strongly  monotonic  and  continuous. 

Definition  C.2.1  (strongly  monotonic).  A  binary  relation  <C  between  domains  Di 
and  ±>2  is  strongly  monotonic  if  and  only  if  for  all  91,92  €  Di  and  for  all  ri,r2  G  E2, 
whenever  9i  (I  92,  9i  ri,  and  92  <  7*2,  then  n  C  r2. 
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Figure  C.l:  Strong  monotonicity  of  <^. 

q2  <  r2  92  <  r2 

U  U  U 

9i  <C  ri  9i  <  ^1 

This  definition  is  illustrated  in  Figure  C.l.  A  typed  family  of  relations  7^  is  strongly 
monotonic  if  each  is  a  strongly  rnonotonic  relation. 

The  following  lemma  says  that  each  simulation  relation  is  strongly  monotonic. 

Lemma  C.2.2.  Let  S  be  a  signature.  Let  C  and  A  be  E-algebras  such  that  each  carrier 
set  of  a  non- visible  type  is  flat. 

If  is  a  simulation  relation  between  C  and  A,  then  "R,  is  strongly  monotonic. 

Proof:  Let  T  be  a  type.  Suppose  qi  C  q2,  ?i  R-iri,  and  q2'Rir2.  Since  q\  C  q2,  either 
qx  =  1.  and  q2  is  proper  or  both  and  q2  axe  proper  elements  of  some  visible  type  with 
a  non-flat  carrier  set. 

If  ±  and  ga  is  proper,  then  since  Ttt  is  bistrict,  rj  =  X  and  ra  is  proper.  So 
ri  C  ra. 

If  qi  and  ga  are  proper  elements  of  a  visible  type  then  gi  =  ri,  and  ga  =  ^a,  because 
TZ-  is  V-identical.  ■ 

The  following  lemma  says  that  each  simulation  relation  is  continuous.  A  typed  family 
of  relations  is  continuous  if  it  is  continuous  at  each  type. 

Lemma  C.2.3.  Let  S  be  a  signature.  Let  A  and  B  be  S-algebras  such  that  each  carrier 
set  of  a  non- visible  type  is  flat. 

If  72.  is  a  simulation  relation  between  A  and  B,  then  72  is  continuous. 

Proof:  Let  T  be  a  type.  Let  Q  be  a  sequence  in  □  of  elements  of  A.  Let  72  be  a 
sequence  in  □  of  elements  of  B,  indexed  by  the  same  set  as  Q,  such  that  for  all  indexes 
i,  g,  72t  Tj. 

If  the  only  elements  of  Q  are  X,  then  the  only  elements  of  R  are  X,  since  72t  is  bistrict; 
thus  lub(Q)  =  X  72t  X  =  lub(i2). 
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Otherwise,  if  Q  contains  some  proper  elements,  then  the  proper  elements  must  all  be 
contained  in  the  carrier  set  of  some  type  S,  since  they  are  related  by  C. 

If  S  is  not  a  visible  type,  then  its  carrier  set  is  flat,  so  the  least  upper  bound  of  Q 
must  occur  in  Q.  Let  j  be  an  index  such  that  lub(Q)  =  qj  E  Q.  Since  7^  is  V-identical, 
the  proper  elements  of  Q  cannot  be  related  by  TZj  to  proper  elements  of  a  visible  type; 
so  R  only  contains  elements  of  a  non-visible  type,  which  is  a  flat  domain.  Since  is 
bistrict,  qj  is  proper,  and  qj  Rt  Tj,  it  follows  that  rj  is  proper.  Since  R  only  contains 
proper  elements  of  a  flat  domain,  lub(/i)  =  r_,. 

If  S  is  a  visible  type,  then  since  R,  is  V-identical  and  R-^  relates  some  elements  of  S, 
72.T  contains  the  identity  on  the  carrier  set  of  S.  Therefore,  for  each  i  and  each  qi  E  Q, 
qi  =  ri  E  R.  Therefore  lub(^)  =  lub(i2).  Since  R^  contains  the  identity  on  the  carrier 
set  of  S,  lub(Q)  R^  lub(i?).  I 

The  following  lemma  says  that  the  closures  of  sets  related  by  a  strongly  monotonic 
and  continuous  relation  are  related.  This  lemma  is  needed  because  closures  are  used  in 
the  semantics  of  systems  of  recursively  defined  NOAL  functions. 

Lemma  C.2.4.  Let  Di  and  D2  be  domains.  Let  C  be  a  strongly  monotonic  and  con¬ 
tinuous  relation  between  Di  and  D2. 

U  Q  Q  Di  and  R  Q  D2  are  such  that  Q  C  i?,  then  Q  R. 

Proof:  Suppose  q  E  Q,  but  q  ^  Q.  Since  q  E  Q,  there  is  some  sequence  in  C,  Qo, 
consisting  of  elements  of  Q  such  that  lub(Qo)  =  9-  Let  /  be  the  well-ordered  set  that 
indexes  Qo  and  let  the  elements  of  /  be  ordered  by  <.  Since  Q  R,  a,  sequence  in 
C  from  R  such  that  lub((5o)  is  related  by  'C  to  its  least  upper  bound  can  be  defined 
inductively  as  follows.  As  the  basis,  let  to  Le  the  least  element  of  the  index  set  /.  Since 
Q  R,  there  is  some  r.^  E  R  such  that  «C  r,o.  For  the  inductive  step,  suppose  that 
Tfc  is  defined  for  all  A:  6  /  such  that  k  <  j.  Let  i  be  the  least  element  of  /  such  that  j  <  i; 
then  Vi  can  be  chosen  as  follows.  If  qj  =  qi,  let  r,-  =  rj.  Otherwise,  if  qj  C.  qi,  let  n  E  R 
be  such  that  qi  <C  r^.  Such  an  ri  exists  because  Q  R.  Since  <C  is  strongly  monotonic, 
if  qj  C  qi,  then  rj  C  r^.  Therefore  Rq  =  {»■,}  is  a  sequence  in  C,  such  that  for  each  i, 
qi  r,.  Since  •<  is  continuous,  lub((5o)  ■<  lub(7?o)-  Finally,  by  definition  of  closure, 

lub(/Zo)  eR.t 
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We  can  now  show  that  the  substitution  property  holds  for  recursively  defined  functions 
that  do  not  use  angelic  choice.  We  treat  the  case  without  angelic  choice  first  because 
this  treatment  parallels  our  semantics  for  recursive  function  definitions. 

Lemma  C.2.5.  Let 

fun  fi(fl  :  S*i)  :  Ti  =  Ei] 

^m(*m  •  SjTi)  •  '^m  ~ 

be  a  mutually  recursive  system  of  NOAL  function  definitions,  where  V  does  not  occur 
in  the  Ej.  Let  S  be  a  signature.  Let  A  and  B  be  E-cdgebrcis  such  that  the  carrier  set  of 
each  non-visible  type  is  flat. 

Suppose  IZ  is  a.  simulation  relation  between  A  and  B  for  NomSig  and  <.  Then  for 
each  j  from  1  to  m, 

(C.12) 

Proof:  For  each  j,  let  Gj  be  the  function  abstract  of  the  form 

fuu(xj  ;  ^■)  :  Tj  =  bottoin[Tj]. 

Let  k  €  {1, . . .  ,rn}  be  given.  Let  q  and  r  have  the  same  length  as  x*  and  be  such 
that  q'E-s^  r.  Let  r]i(xk)  =  ^ and  r}2(^k)  —  r.  By  construction,  rji  'R.t]2. 

Let  be  a  choice  family,  and  let  Qk{^  =  (qi)  be  a  sequence  in  C  such  that 

for  each  i,  qi  is  a  possible  result  of  vM[Z?(fe,,){G/f)]j(i4,T/i).  Let  /?fc(r)  =  (r,),  be  a 
sequence  in  □,  where  for  each  i,  r,  is  a  possible  result  of  772)  and 

qi  TSt*  Such  a  sequence  can  be  found,  because  Z?(fc,,)[G/^  is  recursion- free,  (thus 
Lemma  6.2.1  applies)  and  because  7i  is  strongly  monotonic.  Since  is  a  continuous 
relation,  lub(Qk(^)  TZtj  lub(/?*;(r^). 

Let  DDk{q)  denote  the  set  of  all  such  sequences  Qk{^  in  E  for  all  choice  fami¬ 
lies  and  let  DDk{f^  be  similarly  defined.  By  the  above,  for  every  Qki^  €  DDk(^, 
there  is  some  Rk{i^  €  DDk{f^  (obtained  using  the  same  choice  family)  such  that 
lub(^*(^)  lub(i?^(r)).  Therefore,  we  have 

(lub(«?,{,-))  I  Qt(f)  6  DDtifi]  Ki.  {Iub(fit(r|)  |  ft(r)  e  DDt(f)).  (C.13) 

Since  these  sets  of  least  upper  bounds  are  related  by  and  is  strongly  monotonic 
and  continuous,  by  Lemma  C.2.4  the  closures  of  these  sets  are  related  by 
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Therefore, 


{\nhiQ,{^)  !  e  DD^m 

(C.14) 

{lub(/?fc(f))  I  /2t(r)  G  DDkif)} 

(C.15) 

def 

nBnum 

(C.16) 

So  for  each  j  from  1  to  m, 

■ 

We  must  now  deal  with  recursively  defined  functions  that  use  angelic  choice.  Since 
the  semantics  of  such  systems  is  given  by  first  replacing  angelic  choice  with  erratic  choice, 
we  use  the  following  lemma  to  show  how  the  set  of  possible  results  of  ein  expression  is 
affected  by  this  substitution. 

Lemma  C.2.6.  Let  A  be  an  algebra.  Let  A'  be  a  set  of  typed  identifiers.  Let  t]  G 
ENV (A,  A)  be  an  environment  such  that  for  each  function  identifier  f ,  77(f)  is  monotonic. 
Let  7  be  a  NOAL  expression. 

Suppose  7'  is  derived  from  7  by  replacing  all  the  angelic  choice  (v)  operators  in  7 
with  erratic  choice  operators  (Q).  Then 

Mh'\{A,ri)  Qe  Mh]{A,r^).  (C.17) 

Proof:  (by  induction  on  the  structure  of  NOAL  expressions.) 

As  a  basis,  if  7  is  an  identifier,  bottom [T]  for  some  type  T,  or  the  invocation  of  a 
nullary  generic  operation  symbol,  then  the  result  is  trivial. 

For  the  inductive  step,  suppose  that  the  result  holds  for  each  subexpression.  As  Broy 
points  out  [Bro86,  Theorem  3.2],  the  meaning  of  each  expression  except  angelic  choice 
that  has  subexpressions  71, . . .  ,7n  has  the  form 

Ad[expr(7)](A,77)  =  (J  h{^ 

fexi'?l(i4,T7) 

for  some  monotonic  set-valued  function  h.  In  particular,  we  have  assumed  that  each 
operation  of  an  algebra  is  monotonic  and  by  hypothesis,  for  each  function  identifier  f , 


200 


77(f)  is  monotonic  in  Cg.  If  expr(7')  is  derived  from  expr(7)  by  replacing  all  occurrences 
of  V  with  [],  then  by  the  inductive  hypothesis  we  have  M[')'\{A,r])  Cg 
Therefore, 


Ad[expr(y)l(A,77) 

U 

(C.18) 

Ef  U  *(9^ 

(C.19) 

=  Ad[expr(7)l(A,77). 

(C.20) 

Finally,  consider  the  expressions  71  v 

tion  of  NOAL, 

72  and  the  derived  expression  7([}72- 

By  defini- 

MWMMA.v)  = 

Mly'iliA,^)  U  M[-r'^]{A,rj) 

(C.21) 

M['ix\{A,r))  U  Ad(72l(A,77) 

(C.22) 

•^hidraKA,  77) 

(C.23) 

><[71  V72l(A,r7), 

(C.24) 

because  Afl7i[}72l(^,  77)  differs  from  A^[7i  V72l(-^>»/)  that  the  former  may  contain 
X  when  the  latter  does  not.  ■ 

The  above  lemmas  allow  us  to  reach  our  goal  for  this  section,  which  is  the  next  lenuna. 
This  lemma  shows  that  the  substitution  property  holds  for  systems  of  recursively  defined 
^unctions  that  may  use  angelic  choice.  This  lemma  is  the  same  cis  Lemma  6.2.2  from 
Chapter  6. 

Lemma  C.2,7.  Let 

fun  fi(x1  :  si)  :  Ti  =  Ev, 
fm(*m  ’  Sni)  •  I'm  =  Ej^ 

be  a  mutu£illy  recursive  system  of  NOAL  function  definitions.  Let  E  be  a  signature.  Let 
A  and  B  be  E-algebrcis  such  that  the  carrier  set  of  each  non- visible  type  is  flat. 

Suppose  7^  is  a  simulation  relation  between  A  and  B  for  NomSig  and  <.  Then  for 
each  j  from  1  to  m, 


(C.25) 
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Proof:  Let  /'.(j,o)  Le  derived  from  Ej  by  replacing  all  occurrences  of  the  angelic  choice 
operator  f/;  )  with  the  erratic  choice  operator  (Q).  Let 

f'ln  g(i,o)(x*i  :  s',)  :  Ti  = 

By  Lemma  C.2.5,  for  each  j  from  1  to  m, 

■f(-4)(g(,.0)l  :^(B)|g(,wl.  (C.26) 

The  discussion  of  the  semantics  of  recursive  systems  above  inductively  defines  a  family 
of  approximations  for  the  meaning  of  f  in  j4,  ^(■i4)[g(j,f)l,  and  a  corresponding  family  for 
the  meaning  of  f  in  B,  .^(•S)[g{j.i)l-  To  show  the  result  we  first  show  two  properties  of 
these  families  of  approximations. 

The  first  property  is  that  for  all  j  from  1  to  m, 

■?"(A)(fo,.,|  ^(B)lgW)l-  (C.27) 

This  follows  by  induction  on  *,  using  Lemma  6.2.1  and  Lemma  C.2.4. 

The  second  property  is  that  for  all  natural  numbers  i,  for  all  j  from  1  to  m,  and  for 
all  arguments  q  from  the  algebra  B, 

Qb  ^(B)(gu,«)lW-  (C.28) 

Intuitively,  this  should  hold  because  ^(fi)(g(, ,<+!)]  uses  angelic  choice  for  deeper  recur¬ 
sions  than  ^(5)(g(j,f)]- 

The  second  property  is  proved  by  induction  on  i.  For  the  basis,  let  j  be  fixed  and 
let  9  be  given.  Let  rj  be  an  environment  such  that  »7(x^)  =  q  and  for  all  A:  G  {1, . . . ,  m}, 
=  ^(^)[g(fc,o)l-  Each  f/(ffc)  is  monotonic,  because  the  bodies  of  the  g(fc,o)  do  not 
use  angelic  choice.  By  construction  of  the  ^(5)[g(fc,o)J, 

^(B)(g(;^)l(?1  =  ,).  {C.29) 

X 

By  Lemma  C.2.6, 

A<(%0)l(fl,'!)  Qb  A<(£:,1(B,.|)  (C.30) 
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since  E{j,o)  is  derived  from  E,  by  replacing  all  the  angelic  choice  operators  with  erratic 
choice  operators.  Since  by  construction,  the  set  ,t))  is  closed, 


(C.31) 

(C.32) 

He  M[EjUB,q). 

(C.33) 

By  definition. 

^(B)Ig(y..)l(«T  =  MlEj](B,v). 

(C.34) 

So  combining  the  above, 

^(S)[gU.o)l(?l  Ee  .^(B)|g(y..il(?l. 

(C.35) 

For  the  inductive  step,  assume  that  for  all  j  and  all  q. 


Ee  (C.36) 

Let  t;,_i  be  an  environment  such  that  for  all  k  €  m},  T}{fk)  = 

and  such  that  q(xj)  =  q.  Let  t/,  be  an  environment  such  that  for  all  k  €  m}, 

=  •^(5)[g(fc,t)]  and  such  that  q(xj)  =  q.  By  definition, 

^(B)[gtt, +.)!(?-)  =  (C.37) 

.^(B)(g(,.oKf)  =  A<[£yl(B,>),-i).  (C.3S) 

Furthermore,  by  induction  on  the  structure  of  NOAL  expressions  (as  in  Lemma  C.2.6), 
the  induction  hypothesis  can  be  used  to  show  that 

M{E,]{B,qi)  (C.39) 

So  the  second  property  (Formula  C.28)  holds. 

We  now  turn  to  the  proof  of  the  main  result.  Let  j  be  fixed  and  suppose  qj  7?.g-  Vj. 
By  definition  of  NOAL. 

=  n^(-4)[g(,..ii(9i)  (C.40) 

t 


(C.41) 


203 


Suppose  q  €  Then  for  all  i,  q  E  ^(■^)[gO,t)l(^)-  Since  for  each  i, 

•^(^)[g(j.ol  *»  ^  •^(■®)Ig(i.0)J(o)  such  that 

ri. 

•  If  9  =  J_,  then  since  T^Tj  is  bistrict,  q  can  only  be  related  to  ±.  So  each  r,  is  X, 
and  thus  X  G  ^{,B)\fj\{rj).  Since  q  is  related  to  some  element  of  ^(■6)[fil(rj),  it 
must  be  that  T{A)\fj\{qj)  TJjj  ^{B)\fj\{rj). 

•  If  9  is  a  proper  instance  of  a  visible  type,  then  since  72.  is  V-identical,  each  r,  =  q, 

and  thus  q  G  So  J^{A)[fj\{qj)  72tj 

•  If  9  is  a  proper  instance  of  some  non-visible  type,  then  each  of  the  r,  must 
be  instances  of  a  non-visible  type  as  well,  since  72  is  V-identical.  Suppose 
To  ^  ^(■6)[g(j.i)](^i),  then  ro  ^  n  and  hence  ro  C  ri,  since  ^(B)[g(i,o)I(^j)  Qe 
.^(5)[g(j,i)](rj).  But  since  Tq  and  are  elements  of  a  non-visible  type,  they  are 
elements  of  a  flat  domain,  and  therefore  tq  =  X.  But  this  contradicts  our  iissump- 
tion  that  q  is  proper,  since  72  is  bistrict.  So  it  must  be  that  ro  =  rj.  By  induction 
on  i,  it  follows  that  for  all  natural  numbers  i,  r,  =  tq.  Therefore  ro  G 

So  72t,  nB)ifjm). 

So  whenever  qj  72g-  fj, 

^■(A)[f>l(S)  Ur,  ](?,).  (C.42) 

Therefore  for  all  j,  by  definition  we  have 


(C.43) 
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